Unit testing the database layer

Testing the database layer. Usually an important part of many applications and thus everyone should test it.

But how do you do that?
(if you know how it’s done, this post is not for you, go read something more interesting then!)

You don’t want to setup an Oracle, MySQL, PostgreSQL and such just for running unit tests. Your option? Use an in memory database!

There are a couple of tools available on the opensource market to test your dao layer. I’ve put together an example for a database layer that is using Spring 3.1.2 with JPA2/Hibernate 4.x. For testing I choose the combination of Unitils, H2 in memory database and JUnit.

Unitils is the thing that creates the database using your entities or if you want it can also create your database using an sql script. I usually let hibernate create the database. And add some <dataset> xmls with data.

You can find the example code at github.

Take a look at the tests in src/test/java to see how it is done. There is one test that uses an xml file to populate the database and another test without an xml file. I’ve added Javadoc to the tests to explain what is happening.

This way of testing also allows you to test your service layer with a predefined dataset. Personally I prefer to mock stuff in the service layers. But for doing integration tests it can be useful to have an in memory database.

Happy Testing!

Stop copying that TestSuccessException

Finally you can stop copying that TestSuccessException you write when writing tests with mocking.

I’ve put it in a jar and uploaded it to Maven Central.

<dependency>
    <groupid>be.redlab.testhelpers</groupid>
    <artifactid>testhelpers</artifactid>
    <version>1.0.0</version>
    <scope>test</scope>
</dependency>

The code is on GitHub there is also an EmptyHttpServletRequest, can be useful when calling methods that need a HttpServletRequest as parameter. ( e.g. in Mockito you can’t mock interfaces, so you can mock with the EmptyHttpServletRequest )

At the time being those where the one I needed, want to add more? Just leave an issue on GitHub and/or send a pull request for interesting stuff.

Stop sleeping, start awaiting

On Devoxx there was a quicky session named ‘Stop sleeping, start awaiting’

The speaker presented Awaitility. A test-framework for helping you out waiting on objects. Mainly usable for testing asynchronous code in unit testing. A unit test does not wait for code to be executed, developers tend to use Object.sleep(xxx) but this will not always work. On some systems the xxx needs more milliseconds then on others. In the end you’ll be waiting ( rather sleeping) while all the tests that have sleep() run. The whole testsuite will go very slow.

Awaitility is a framework to help you wait for code to be executed,
It goes like:

await().untilCall(wrappedCallMethod).statusOf(xxx).is(OKAY);

It’s like a mocking framework. Personally I do the same with mockito and java.util.concurrency waiting and locking classes. But perhaps Awaitility will make you create the tests faster.

This is certainly one framework I will try out!

%d bloggers like this: