Otaku, Cedric's weblog lists a few woes of DbUnit. Here are few answers to Cédric's post.
We've been using DbUnit for a year now with our automated tests and we have no problems with getting connections and we have literaly hundreds of tests running every hour.
You don't have to have your test data in a separate XML file. The xml is just used to describe a single line in the DB. If you look at how you inject data into the DB, you don't have to do it through a file like the docs recommended (at least the old ones), you can do it from a String.
In our test suite, we have an XML file for every table which we use in 99% of the tests. It's really just an extract from the original test database.
For very special test cases, we inject a string contained in the test code instead of the whole XML "table".
We have found this method to be invaluable just to be able to handle references and constraints.
You could also go overboard and have a single XML file define the whole database but we decided against that for maintenance purposes.
About Cédric's properties file comment : I agree but it's more "wordy" and breaks the natural inclination people will have in reading a single XML line as a single database row.
I haven't tested version 2 yet but there was a problem similar to the one described in Cédric's second post in version 1.5.x. Omiting a "column" in the XML definition resulted in the column getting NULLed. Omitting the column on the first row getting inserted resulted in all rows getting that column NULLed even if the other rows had the column valued.
Why would you write your own framework on top of JUnit rather than DbUnit... Why would you ? I like all of DbUnit except the NULLing column bug, really don't see anything wrong with it.
An article about DbUnit and how we have used it is in the final review process at developerworks...