The article is the result of an experience on a past project I worked on recently. It was a simple desktop Java system whose goal was to read data from a bunch of database tables and configuration files and generate several output files formatted in a specific way. We had a simple persistence layer with DAOs implemented with JPA/Hibernate.
The entire project was developed with automated tests (unfortunately, most of it did not use TDD, 😦 ). In order to test the DAOs (some of which had rather complex SQL queries), we had integration tests written with JUnit and DBUnit along with an in-memory HSQLDB database. For simple DAOs (and respective domain objects), that approach worked quite well. However, for the more complicated ones, we started to have a few hard-to-understand tests, since a lot of fixture code was being required to set up the data needed for the tests.
So, we wondered if there would be a way to express the integration tests for our DAOs in a more readable way. Now, our project dealed with accountancy data, so we thought that it would be perfect if we could express some of our tests in tables. That was when FIT came to our mind. FIT is a tool which allows one to write automated tests in a tabular format (it uses HTML tables). Just what we wanted!
So, we were able to successfully convert our automated JUnit tests of DAOs into highly readable HTML fixture tables. Now let’s talk in more details about how our previous strategy was and how it changed with the introduction of FIT.
Using DBUnit, our HSQLDB test database was set up with the test data in an XML dataset file before the execution of each integration test. Then, we would have to construct the list of objects that would be the expected result of the call to the DAO’s method under test. Besides being difficult to read (though we experienced some improvement by using test builders), those objects evidently had a lot of duplication with the data in the XML dataset.
Our approach with FIT was to put all the necessary setup data together with the test itself in the HTML document (each DAO has its corresponding tests in an HTML), removing the XML datasets. The first section of the document, which is the configuration session, starts with the tables containing the data to be inserted in the test database. The last section of the document contains the test scenarios with the actual tests and expected results. The HTML test document was implemented using the Flow Mode of fitlibrary‘s DoFixture. Inside the Flow Mode, for the first section of the document we used the SetUpFixture (also from fitlibrary). The corresponding Java glue code for the SetUpFixture, in turn, used DBUnit’s DefaultDataSet to programatically build the dataset with the contents of the HTML setup tables (which then were inserted in the HSQLDB database just like before). We ended up creating a few utility classes to enable DBUnit to configure the test database with the data from FIT tables.
Even though FIT has been designed for the automation of acceptance tests (hopefully with customer colaboration), we found it pretty effective to be used to test data access code of data-driven applications. At the end, we had highly expressive integration tests that looked like executable specifications.
In the article, our approach is fully described using a working example and showing all the related code. Comments and suggestions are always welcome!