Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  Jimmy Hoffa Sep 19 '12 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 Sep 19 '12 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 Sep 20 '12 at 2:34

3 Answers 3

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)?

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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