views:

85

answers:

2

I'm developing a Domain Model based on the Repository Pattern and all of my Unit Tests as part of TDD are going against a Test Repository.

My question is: at what point do I create integration tests against the SQL version of the Repository?

My concern is that the code to access data from objects (Test Repository) will work fine. But the database version (SQL Repository) is so different under the covers that my vital code in the SQL Repository will end up not working and be in itself untested. How do I ensure that it's working as intended? Am I missing something about the process?

Regards.

+3  A: 

You should have tests which mock out the repositories (as it looks like you do), that doesn't query the database itself, but return results as if they did. These are the tests for functions that call the repository functions.

But it is also useful and recommended to have tests that check the database itself, and check if they return what they should. They should be also "unit tests", not depending on other stuff. Try not to depend that the database is on a determined state, but instead, make a setup to build your database initial state.They will probably be slower, and may not be run on every commit and build (I mean, don't run if it really takes a lot of time).

Finally, in your integration tests, do all the stuff you should do.

Samuel Carrijo
A unit test by it's nature doesn't touch external systems. So the tests that would run against the SQLRepository would be integration tests. Beyond that I agree completely with this answer.
ShaneC
A: 

In my opinion, as soon as you have the corresponding database code that your unit under test depends on go ahead and also add integration tests that use the real repository. Faking and stubbing things out make unit testing easier and allows you to concentrate on a particular aspect of your code without getting frustrated by external dependencies and setting them up correctly. However, at the end of the day, you're not shipping products with stubs, fakes, and mocks. The shipped product has real dependencies and components that all must work together. Therefore, whenever you run your tests, you need to know if parts of your applications are working together or not. If a part of my application is not able to persist changes to the database, I would like to know it as soon as possible. So if your external dependency, database in your case, is at a level where it is providing some level of functionality and value to your code, go ahead and add a suite of integration tests.

Note that running integration tests will usually take longer than unit tests. So you may want to run just the unit tests during your CI builds. That way, you get a feedback on the health of your build and codebase quicker. However, you should include integration tests in your nightly build so that you know how your code is working in reality.

Mehmet Aras