leonardoborges.com

the not so usual geek stuff…

When testing it’s pretty common to see the need for mocking a certain object, say, a Data Access Ojbect. This way you don’t need to depend on a database and you can focus on the actual logic implemented by the method being tested.

For that you have several alternatives like creating the Mock class by hand or - and this is the more common - use one of the various mocking libraries out there.

They all look the same but the past couple of days I’ve come accross to a new - at least for me - mocking library for Java. It’s called Mockito. As the creators state, technically, Mockito is a fork of EasyMock.

I have used EasyMock already but I do think Mockito has its advantages. I find it clear and a bit less verbose to write.

From one of the stubbing examples on their website:

//You can mock concrete classes, not only interfaces
LinkedList mockedList = mock(LinkedList.class);
 
//stubbing - before execution
stub(mockedList.get(0)).toReturn("first");
 
//following prints "first"
System.out.println(mockedList.get(0));
 
//following prints "null" because get(999) was not stubbed
System.out.println(mockedList.get(999));

Looking forward to using it in production!

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:

Read the rest of this entry »