First a bit of background: We are re-architecting our product suite that was written 10 years ago and served its purpose. One thing that we cannot change is the database schema as we have 500+ client base using this system. Our db schema has over 150+ tables. We have decided on using Entity Framework 4.1 as DAL and still evaluating various frameworks for storing our business logic.

I am investigation to bring unit testing into the mix but I also confused as to how far I need to go with setting up a full blown TDD environment. One aspect of setting up unit testing is by getting into implementing Repository, unit of work and mocking frameworks etc. This mean there will be cost and investment on the code-bloat associated with all these frameworks. I understand some of this could be auto-generated but when it comes to things like behaviors, that will be mostly hand written. Just to be clear, I am not questioning the important of unit testing your code. I am just not sure we need all its components (like repository, mocking etc.) when we are fairly certain of storage mechanism/framework (SQL Server/Entity Framework). All that code bloat with generic repositories make sense when you need a generic layers with ability to change this whenever you like however its very likely a YAGNI in our case. What we need is more of integration testing where we can unit-test our code with concrete repository objects and test data in database. In this scenario, just running integration test seem to be more beneficial in our case. Any thoughts if I am missing any thing here?

  • 1
    Since you are re-architecting, the "code bloat" (I can only assume you mean interface layers which create loose coupling which is a good thing) you're referring to, will actually result in a more stable well designed system. Now is the single best time to introduce these good design habits. I know it's often hard to recognize the value in good design when you've been living in bad for so long, but it truly is good design to force boundaries between layers. It will make the software capable of withstanding change to live another 10 years. Commented Sep 19, 2012 at 1:19
  • @Jimmy: Yes that's exactly what I mean by code bloat. Of course we will be doing good design. There are tools available for ensuring that you are creating layered boundaries with right dependencies. Its just that I am having hard time convincing for the cost associated with all that code bloat. I think with integration testing as part of builds, we should be able to ensure that we are doing right tests.
    – palm snow
    Commented Sep 19, 2012 at 2:31
  • you don't unit test against an actual database because you're not testing the data, you're testing the logic that calls the data. And in many cases, there is no data when the code is being written anyway. And the code bloat you mention is largely sound oop practice. Thorough tdd will always save you and your clients $$ in the long run.
    – Forty-Two
    Commented Sep 20, 2012 at 2:34

3 Answers 3


Apart from speed as psr mentioned, unit tests avoid hitting the database/repository to help isolate errors. The solution is not creating a generic repository. Instead, it is allowing the repository to be swapped out for a test repository that checks whether the business layer/model is making the correct repository calls. Similarly, a stub business layer/model can make test calls to a repository in a known state and compare the results to known correct values.

Doing an integration test using the repository is also a good idea but serves a different purpose to your unit tests. The challenge with doing the full integration tests as part of unit testing is ensuring tests and test data do not interfere with or impact others, such as a developer working on changes.


Unit testing against the database means you actually have a test database. In general, that is overhead in and of itself. The sort of overhead that isn't the rock solid, repeatable, concurrent type that unit tests need to be effective.

  • DB is down? tests fail.
  • Network is down? tests fail.
  • Working from home? tests fail.
  • Someone didn't deploy the test data properly? tests fail.
  • Someone running another test at the same time? tests fail if you're not careful.

Your tests should only ever fail in one case: the thing they're specifically designed to test does not pass their assertion.

Now these can mostly be dealt with by having a locally deployed database new each time from test data. But how is that really any different from Mock repositories (except being slower and more error prone)?

  • The implementation cost of Mock repository varies with technological choices. Sometimes, companies choose to "going all-in" (as opposed to hedge) by sticking with a single implementation stack (as in OP's case with Microsoft) to save implementation cost. If the implementation stack does not have mock framework baked in, it will unravel the original architectural decision of going all-in. Fortunately, it looks like EF 6.0 adds support for mock testing, so this architect doesn't have to regret the decision for years to come. (Yep this comment is a tad too late...)
    – rwong
    Commented Jan 3, 2015 at 4:47

Your tests will be much slower if they all hit the database, so you probably won't be able to run them nearly as often, or you will spend a lot of time waiting for them. This is a big deal, because you want to run your tests quite a lot.

Also, it's tough to get a huge benefit out of re-architecting if you can't touch the schema. You might take a look at Evolutionary Database Design which talks about how to develop against a changing schema. I admit that data migration is hard, but so is re-architecting an application, and you are taking that on.

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.