I have blogged before about my experience with database development and how it feels like stone age if you are coming from the object oriented world. Obviously an area where a lot of improvement is needed.

Here is somebody else working on that problem. He is aproaching the problem using FIT or at least based on fit:

That’s the hardest part about testing code that depends on the database: setting up the data the way you want it, and making sure it’s there in a pure and unadulterated form (otherwise, you may get incorrect results). What better way to declare your test data than to put in it tables, just the way it should look in the database? So, we made special set up fixtures that let you declare the name of a table and the columns into which you want to insert your test data. Each row in the HTML or spreadsheet declares a row that will be inserted into the database before the test begins.

Unfortunatly the tool he talks about isn't open sourced, but I think it is an interesting aproach worth considering when you do database centric software development.

He talks also about code coverage analysis for database code and promises to cover that in a future post in more detail. I do look forward to that post.

One other piece that is typically missing from the database development suite are tools for reporting on test coverage of procedural code by the unit test suite. [...] Our Data Architect, has come to the rescue with an excellent, thorough and flexible solution to this problem. Unfortunately, it’s Oracle-specific, so it will only help you if you work with Oracle. I’ll save the details for another post - stay tuned!