However, like almost all tutorials for DbUnit, this plugin assumes that the best way to organize your test data is using DbUnit's FlatXmlDataSet. The example given on the Wiki link above has this FlatXmlDataSet:
During my 5 years of working with DbUnit, I have come to the conclusion that FlatXmlDataSet is not the best way to organize test data. Here are my reasons:
- XML is not a good representation for tabular data. CSV is more readable.
- For most of my tests, I would rather see the test data together with the test, rather than separate.
DbUnit tests often have 3 "phases":
- Prime the database with setup data.
- Run some code of the System Under Test.
- Verify changed data in the database.
For most of my DbUnit tests, I would like to see the data used for the first and last parts together with the test itself.
For this reason, we've gravitated towards inline CSV datasets in most of our DbUnit test cases. You can achieve this using Groovy in Grails very simply.
The Wiki example, used in a test with inline datasets, might look like this:
(I'm using pipe characters instead of commas in this case!)
If the same Person data were used in different test methods, we might factor it out into a common method or field.
What I tend to find is that I use a lot of common reference data in my tests, but test-specific detail data. I handle the common reference data in a setUp() method, or even in the base DbUnitTestCase class. I put the test-specific detail data in each test. This prevents duplication of the common stuff, and keeps each test clean and focused. By reading the test method, you can see everything involved in the test.
We define cleanInsert() and a few other conveniences in DbUnitTestCase: