DEV Community

Discussion on: How to setup methods which return a built-in type and implement IEnumerable interface in Moq ?

Collapse
 
justinjstark profile image
Justin J Stark

Why are you returning a DbRawSqlQuery rather than an IEnumerable? Maybe you have a reason but you can avoid this mocking problem if you change your method signature to

IEnumerable<UserVesselPermissionsResult> GetUserVesselPermissions(Guid userId, DateTime date);

This also means consumers don't take a dependence on System.Data.Entity and your method technology can freely change with no change to consumers.

Another indication that something isn't right is you are writing unit tests for a method that returns an ORM-specific type. This leads me to ask the questions: Is your unit test useful? Could it be more useful if you abstract away the DbRawSqlQuery? Would you be better off writing your unit test at a higher level of the application?

Collapse
 
rajmondburgaj profile image
Rajmond Burgaj • Edited

Hi Justin, sorry for the late response. In my case I would have changed it to be IEnumrable but did not want to do so because I had to change many things in the services which I did not want for the moment. Maybe a later a refactoring task might fix this. In reality there might be a reason why you don't/cant change to IEnumerable because you might want to use some extra functionalities provided by the class(in this case DbRawSqlQuery) without having to cast first. But I agree with the fact it is better where possible to keep as less dependencies as possible.