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!

Hibernate & JPA 2.0

I started to follow this session after the break so missed the first part.

Just after the break of JPA 2.0 by Emmanuel Bernard, Karel Maesen pops up. He’s giving an introduction to Hibernate Spatial. It seems that development on it is increasing again. With on going implementation of support for more databases (like Ms SQL server and DB2) furthermore in hibernate 4 the rumour is that hibernate-spatial will be included in hibernate’s core. (making it bigger … is that good? perhaps it’s better to leave it seperate)

Karels talk was just an intermezzo. Emmanuel continues with Hibernate Envers. A framework for versioning your data. It can be used in any existing hibernate application. There will just be some more tables (the history tables). Add @Audit to your @Entity classes and they will be versioned. With every crud operation in normal hibernate the changes are transactionally applied to the history tables. This of course comes with a reduce in crud speed.

The versioning is done with revision numbers (like svn? ), the revision number sequence is stored in a separate table together with a time stamp and optional additional data defined by developer.

Envers provides some helper classes/queries to retrieve the historical data through the AuditReader. You can retrieve objects by revision number or between different revision numbers and/or dates. In the example this is all done with Java code, like the CriteriaBuilder in JPA 2.0

Emmanuel goes on about the Hibernate Validator which is actually now a standard in EE6 (the Bean Validation spec) now. It works in JPA entity persist, update, remove and on presentation layers like JSF 2, Wicket and more. There is even a project to integrate Bean validation with Flex. Hibernate will reflect the constraints to the database if you let it generate your tables.

One could easily creates is own specific validation annotations with Hibernate Validation. Validator also adds the possibility to add ConstraintMappings to it. More ongoing parts are the method level validations allowing you to use the validator not only for Entities. (Just like Bean Validation in EE6 I thought…

Another project is Hibernate OGM where the idea is to store indexes from Hibernate Search into Infinispan. They didn’t think it would work but why wouldn’t it… Hibernate Search would delegates the search to OGM which stores the results in Infinispan and afterwards Hibernate Search retrieves the results from Infinispan. This is an ongoing project. So not yet released. Note because Infinispan is used, this is automaticly distributed!