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.