Before starting, this question is not the same as this one.

Comming from a PHP background, my experience is in CakePHP, which is a framework that supports Unit Testing by setting up a local test database, handled by special classes called fixtures (let's you CRUD data on the test db before each test suite via code).

However, being new at .NET framework, intermediate tutorials suggest the use of Unit of Work pattern, in order to either use a real repository or a mock repository via an interface.

When it comes to unit testing, there isn't much difference between this 2 ways of handling data operation, but the issue I encountered was when loading relational data, as the real repository uses the framework's ORM while the mock repository use something similar to a List interface implementation to keep data in memory, and it isn't able to eager load nor lazy load relational data.

Up to this point I see 2 possible reason I stepped onto this issue:

  1. The mock repository should be coded so that it can somehow get relational data.
  2. I shouldn't be testing whether the model acquired related data, but test only whether the controller was able to acquire the main model from repository.

I'd like to know which of the 2 above would be it (or if maybe there's a 3rd one...) and the advantages/disadvantages of mock repository vs test db.

  • You explained what your issue is (in your third paragraph), but you didn't explain why it's a problem. Commented Feb 6, 2015 at 16:42
  • It is a problem because when testing for CRUD operations on related data, a mock repository wouldn't be able to handle it that easily, you would have to code a lot just to mock that; while a test database would handle it by default Commented Feb 6, 2015 at 16:46
  • Generally, mocks just return some predetermined values, so that you can isolate that part of the code from the test. If you're testing elaborate data sets, yes, a database would be easier (and probably more realistic). Is there any reason you couldn't just avoid the CRUD tests? Frameworks like CakePHP are already tested; you shouldn't be testing the frameworks themselves in your own tests. In other words, you shouldn't be checking to see if CakePHP can return CRUD (assuming it's run-of-the-mill CRUD). Commented Feb 6, 2015 at 16:56
  • So the issue I'm having is number 2, I shouldn't be testing that right? (I'm relatively new to TDD so I'm not sure yet what is it that you are supposed to test) Commented Feb 6, 2015 at 18:48
  • Standing up a bunch of TDD to define requirements and verify functionality on something that's already written by someone else seems not only a waste of time, but diametrically opposed to the whole notion of TDD (since, in TDD, the tests are always supposed to come first). I would focus your TDD efforts on your specific project's functional and non-functional requirements. Commented Feb 6, 2015 at 18:49

1 Answer 1


Given a scenario, when some method is called the data must be persisted into db and have following steps:

  1. Setup empty db simulator (you call it mock) and pass it in as a dependency
  2. do call the method you are testing
  3. Verify the data was stored in simulator


  1. Setup db simulator with predefined data and pass it in as a dependency
  2. do call the method you are testing
  3. Verify the method operates properly on the data retrieved from simulator

Can you clarify which scenario you are having troubles with with relational data. It is whether persisted into simulator or retrieved from it.

If you are testing the logic that happens in your data layer you will end up testing the test code (mock setup specifically) and not the real system - such tests are to be avoided as they bring no value.

For example if you have a trigger that adds a log entry on update operation and you want to write the test that updates a record and checks for new log entry, there is no way to unit test that. You must not rely on mock to do that for you. Write integration/functional tests against real system instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.