leonardoborges.com

the not so usual geek stuff…

I never paid too much attention on testing database stuff. While working with java, the closest I got to something workable was using the test case abstractions provided by the Spring framework. It ensures that each test method runs in its own transaction that is rolled back after the test’s execution.

Fair enough. I used the setUp() method on my TestCase to configure some records so I could work with them, removing all of them in the tearDown() method. It was quite simple and worked.

But I always felt something strange with this solution. First of all, I had to add another framework just for that. - Actually I was using spring for dependency injection, but if I wasn’t, it wouldn’t be a nice option. And another thing that bothered me, is that you cannot guarantee that your database is in a known state.

After I started to work with Ruby - and Rails - I discovered the testing fixtures. It is a really nice way to set up your testing data without having to worry about your database state. - If you don’t know what I’m talking about, follow the above link first.

Then I received a message from a co-worker saying he was having some trouble in using DBUnit with Hibernate, and asked for some help. I’ve heard of DBUnit before but never tried it myself. It was a very good opportunity to take a better look into it.

The basic idea after all is very similar to that of the Rails Fixtures: You have some sort of external file - XML in this case - where you set up the testing data. So the framework takes care of erasing the database, inserting your test data and returning it to its original state.

So far so good, DBUnit’s default Classes works with JDBC, DataSources and JNDIDatasources, but not with Hibernate. The effort to put them working together is minimal and is documented in their web site.

I decided to share how this can be done with hibernate and in the end, you would have a test case similar to this one:

[java]
public class DBUnitTest extends TestCase {
private Session s;
private FileInputStream is;
private IDatabaseConnection conn;
private IDataSet dataSet;

public DBUnitTest() {
try {
s = HibernateUtil.getSession();
is = new FileInputStream(”task-sample-data.xml”);
conn = new DatabaseConnection(s.connection());
dataSet = new FlatXmlDataSet(is);
} catch (Exception e) {
e.printStackTrace();
}
}

@Override
protected void setUp() throws Exception {
super.setUp();
try {
DatabaseOperation.INSERT.execute(conn, dataSet);
} catch (Exception e) {
e.printStackTrace();
}

}

public void testTrue() {
List tasks = s.createQuery(”from Task”).list();
for (Task task : tasks) {
System.out.println(task.getId());
System.out.println(task.getDetails());
}
assertTrue(true);
}

@Override
protected void tearDown() throws Exception {
super.tearDown();
try {
DatabaseOperation.DELETE_ALL.execute(conn, dataSet);
} catch (Exception e) {
e.printStackTrace();
}
}
}
[/java]

Note that you don’t need to extend any DBUnit class. You extend only Junit’s plain old TestCase. In its constructor I set up everything I need: The session factory (through the HibernateUtil), and use it to get a session’s connection, needed for DBUnit.

This example is quite simple and I decided to keep it like this to show everything working together. But you would more likely make this class abstract with an abstract method, say getDataSet() so your subclasses wouldn’t have to worry with DBUnit at all.