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?