In the previous post we have seen how to use DbUnit to write a simple database test. By using DbUnit for this purpose, we were able to insert a complete dataset into the database without writing SQL. However, we had to use XML to specify the dataset:
Now, you can think about XML what you want but I (and hopefully most people) would rather not want to write such files but instead create the dataset directly in the code of the test class. As it turns out, this is very hard using plain DbUnit.
DataSetBuilder to the rescue
So, I thought, wouldn’t it be nice to have a builder for datasets with an easy-to-use API? Thus, I sat down and wrote DataSetBuilder for DbUnit.
Here’s how it can be used to replace the
dataset.xml file from above:
Lots of strings you might say. That’s what I thought as well. In addition, it’s not typesafe at all. You could insert a string into the
AGE column for example. To circumvent this problem there’s the
ColumnSpec<T> class which represents a column of a certain type
ColumnSpec the first row in the previous example can be written as:
Now, inserting a string into the age column would cause a compile error:
You can extract constants for the
ColumnSpec instances and collect them in a class per table to be shared and used by all your database tests:
After the refactoring, our
buildDataSet method looks like this (using static imports for the constants):
This approach has another advantage: The tests can easily be adapted when a column is renamed. All it takes is changing the string parameter of the
newColumn method. Now, try to do that with numerous XML files…
To sum up, this post has shown how DbUnit can be used without maintaining XML files. Instead, the datasets are build directly in the test code.
In the next post of this series on database tests with DbUnit, we will explore how our database tests can be made even more robust against changes of the database schema such as adding or removing a column.