如何在C＃中对firstordefault（）进行单元测试？

Question

I want to mock the below line of code(by MOQ in C#,MVC) :-

CustomerDto target = CustomerService.GetAllCustomer().FirstOrDefault(n => n.CustomerID == customer.CustomerID);

Where CustomerService.GetAllCustomer() function is the dependency in the controller method.

Where it is using FirstOrDefault() function.And in unit testing i have no clue how to mock it.

Can any one suggest me way for it ?

Answer 1

Mock(stub) your dependency only . In this case it is CustomerService, which should be some interface or abstract class implementation. Make your GetAllCustomer method return some fake customers. FirstOrDefault is a .NET Framework method which should not be tested (it is already tested by the framework developers)

Answer 2

IMO, you need to start decoupling your code by moving towards a more layered approach. I am not quite sure what you need to achieve by mocking the FirstOrDefault method. I suggest having three layers and their tests as below -

Data access - uses EF and its DB context and implements a data access interface. You should unit test this without mocking EF's db context. Tests for this layer would be "state" dependent. By that I mean, your tests will work with real data and database for the CRUD operations. You just need to make sure you do not persist the changes to the db after the test run. One can use Spring.Net's testing library to achieve this or simply run your tests under a transaction scope and roll back the transaction after every test run (in the clean up).

Business logic - contains the business logic and works with the data access interface. Use any DI framework like spring.net or ms unity to inject the data access layer. You should unit test this by trying to avoid actual database calls. This is where something like a NMock, Rhinomock or MOQ comes into picture. Set up boundary and exception conditions using mocks and make sure your business logic addresses all the concerns.

MVC Controller - Will delegate the calls to business logic layer and most probably handle stuff like notifications etc needed on the UI. It should be a judgement call if the controller really needs to be unit tested. It could be an overkill more than often. I would rather suggest considering automated UI test cases using something like selenium or Microsoft's coded UI tests.