On Unit Testing and TDD
Just read a couple of interesting posts. One provides a set of anti=patterns for TDD and the other looks at how best to Unit Test the db layer.
Anyone else have thoughts on DAO unit testing or TDD anti-patterns?
The problem then is that you've added/update/deleted data.
This is less a problem on your development environment, but it would be nice to have a test on production to give users the confidence that "everything's working" (after a power failure for instance). I posted an old listserv message about this on the "Best Served Cold blog" at
http://www.pjk.us/paul/index.cfm/2007/3/2/Your-tho...
In my interpretation of Star Trek parlance, a level 3 diagnostic would be to test all your SELECT stmts.
A level 2 diagnostic would be to test all your CRUD methods.
A level 1 diagnostic would be to automatically correct any errors.
"How could you do that?" You might ask.
I can think of one example right off the bat: Views.
Views tend to break when the underlying table structure changes. To correct the view, you simply have to recreate it. It could be as simple a view as
SELECT * FROM tblname.
But if tblname changes, the view will no longer be valid.
A level 1 diagnostic would report the error and fix it.
My plan is:
- primary keys are UUIDs; Test data can be added and removed even from production database (there is also requirement to export/import data and this helps with that as well)
- for each database table created I have drop scripts so during development I can always start from clean database when testing. Scripts are executed with Ant.
- I have several XML files that populate database with DbUnit/Ant. Some of them are just for development/testing, some contain static classifications for actual database.
I hope this solves some of the issues I've had before testing application where certain state of database is required but was difficult to do.