0

I am somewhat new to unit tests so hopefully this question makes sense.

My Setup: Visual Studio 2010 Entity Framework 4.1 Moq

I have a Service class located in my BAL which uses the UnitOfWork in my DAL. The UnitOfWork manages access to various repositories which in turn access the database through a Context object.

I would like to create a unit test for a service class public method which is responsible for some very complicated "GetNextObject" type logic utilizing lambda expressions.

Question: I can very easily Mock my DBContext and create a DBSet of objects that I want to test my Services method against(the service class essentially queries the repository). Is this the correct way to do this or is this more of an integration test? By mocking the Context I have removed the database, but I still am using the UnitOfWork and Repository classes. Should I instead do a complicated mocking of all these objects?

Thanks! AFrieze

AFrieze
  • 844
  • 1
  • 10
  • 26

1 Answers1

0

Assuming your service only depends on repository and unitofwork, you don't have to mock DbConext, do you? Generally, we don't mock DbContext mainly because there is not much to test since repository/unitofwork are basically wrappers of dbcontext. In order to test your services, mocking repository and unitofwork should be enough. If you want to test DB operations, do the integration test.

Tae-Sung Shin
  • 20,215
  • 33
  • 138
  • 240
  • Basically I have a method in the service class that uses the unitofwork/repository to query for objects. I want to test the query logic and make sure I'm getting the correct objects. My thought was to mock the context and essentially use an in memory database setup to test different situations. – AFrieze Aug 12 '11 at 20:25
  • You can test the query logic by mocking unitofwork/repository, right? I belive this answer serves you better. http://stackoverflow.com/questions/6766478/unit-testing-dbcontext. – Tae-Sung Shin Aug 12 '11 at 20:31