Otaku, Cedric's weblog

DBUnit doubts

I was looking forward to converting my database tests to DBUnit, created by Manuel Laflamme.  The idea of being able to specify my test data in an external file was appealing, as was the fact that DBUnit is a thin layer on top of JUnit, so I was confident I would feel comfortable with the product.

Unfortunately, things turned out differently.

First of all, I still haven't been able to get it to work.  For some strange reason, my getConnection() never gets invoked.  I am not extremely worried about that, I know I will eventually figure it out, but why is it that every single open-source product that I try never works as advertised out of the box?  Why do I always have to become much more intimate with their source base than I would like to?

Another sadly typical thing in open-source projects is that if you go to DBUnit's home page, there is no obvious link to the documentation.  I give them points for putting the Download link on top, but if I am trying to evaluate your product, why would I care so much for Changes, FAQ, Getting Support, Source or JavaDocs?  Just point me to a simple white paper of a few pages explaining why I should care about your product.  To make matter worse, the only page that provides some assistance tells you that the documentation can be found in the release.  Come on, now, just make the darn thing available online and make sure it sits right up next to the Download link.

Anyway.

The real problem is the idea behind DBUnit.  I started realizing that specifying the test data in an external file didn't make that much sense after all.  If you are going to modify the said data, you will be modifying your Java code as well, so the maintenance cost is pretty much the same in both cases.  Except that if you initialize your test data in the code, you get an additional way of testing your database code, and you are also probably closer to the way your users will initialize their own database.

Another hint on the questionable premise of DBUnit can be read in the author's own comments.  He initially started with a generic XML format to describe the data that your database should be initialized with.  Then, in the next version, he makes the following observation:

The FlatXmlDataSet class has been introduced in version 1.2. I found that generic XML datasets were hard to write and to maintain. This was particularly painful for tables having a lot of columns.

This new XML format is more generic but also dependent on your database schema.  It's a progress over the first iteration, but it's a pity that Manuel didn't push this realization to its conclusion:  you are trying to model relational data, XML is not a good way to do that because it is hierarchical.  From a practical standpoint, I see very little difference in verbosity between FlatXmlDataSet and plain Java code.  I would argue that a dumb properties file would probably be the easiest choice:

person.row0 = "Beust", "Cedric", ""
person.row1 = "Purdy", "Harold", "C"

I really want to like DBUnit, but at this point, I see very little added value compared to writing my own framework on top of JUnit.

Can someone convince me otherwise?