I agree that you need to test against a live database, but I think that testing against a mock database is also a good thing.
The reason? They test different things. Testing against a mock database tests that the code makes the requests you expect, and handles the data how you expect. Testing against the live database verifies that this aligns with how the data really is.
Mock objects only allow to test the sequence of calls to test the logic of your application
Live database is a must especially when youre talking about complicated data entry application
Mianly for:
1. Validating that the database is not curropt with its logic
2. testing for performance issues your application
3. testing on all kinds of data scenarios your code.
Hate to say it but:
Told You So ;)
I agree that the techniques you promote here are valuable techniques, and we have been using them for over a year. I have also come the acceptance that a first choice for working with unit tests and database supported code could/should be a test database. But, I can tell you with absolute certainty that this solution does not work well on large projects. It's most reliable when using the rollback type solution, but this also represents the worst case for speed of the tests. Other options like restoring the database to a known state are problematic, though I have been experimenting with techniques to make that faster than a full restore allows. Having the tests cleanup after themselves can be made to work with a lot of discipline, but handling all of the exception cases makes that approach pretty hard to be rock solid reliable.
My current test suite. based mostly on test databases and manual cleanup and rollback techniques, takes over 45 minutes to run 8^(
I disagree, but...
Testing against a live database is a good thing to make sure that your code integrates well with your data source. However, this is not a "unit" test -- it's an "integration" test.
Integration tests are good for various reasons and should be run now and then, but they are typically way too slow for a good set of unit tests. Different people have different objectives and practices, but I like to run all the unit tests very often... typically after changing just a few lines of code. Using a live database makes this unproductive and unbearable.
Check out Rainsberger's "JUnit Recipes". He has some good suggestions for this sort of testing.