techno.blog("Dion")

I was listening to a Hibernate presentation given by Rod Cope (of BlueGlue), and was excited to hear him say that one of the features coming in Hibernate 3, is the ability to persist to other forms (not just RDBMS). Maybe in a pluggable way.

I was surprised to hear this, as Hibernate has always had the notion that RDBMS is the pragmatic approach which 99% of people use for persistence. However, I welcome the pluggable implementation.

One of the biggest reasons I would be excited to see it, is because of what it could offer me in my testing department.

Let’s look at how we often do testing now.

Testing without the DB

We currently have a mechanism which uses DBUnit to make sure that the DB is in a known, stable, state for our tests to run. We have some nice maven goals which allow us to build this stable state from a test database itself, and then DBUnit takes care of making sure the state is correct for us.

Although this works well, in that our tests run the full gamit and are well tested, it is far too slow to employ this technique in a scalable way on a project.

For the majority of our tests (ideally all but those which tests the DAO layer itself) we have a flag that we can turn on, which tells our friendly services layer cop, Spring, to load the Mock DAO classes. These bad boys obviously implement the same interface as those which talk to the DB in some way (e.g. via Hibernate or Kodo), but do so in a faster way. They fake the tests by loading up an in-memory set of objects (Hi, Prevayler, stop sulking, you *are* still useful!). This turns our test speed to a minimal level, allowing the developers to not get into the habit of using -Dmaven.test.skip=true.

We can also run integration tests which do not use the mock layer, and make sure that our tests run fine when they go through all layers, right back to the DB. This can run once a day, and hit us with the lovely CruiseControl email if something is foobar’d.

While this all works great, and can be used no matter what data access method we employ on a project (e.g. if we have to have some areas use pure JDBC), wouldn’t it be nice to have this be even more transparent?

Hibernate + In Memory Pluggable Persistence

This is where the idea of plugging different backends into Hibernate looks attractive. It isn’t so much to be able to talk to an LDAP server, an OODBMS, or even an XML file system. I would love to be able to have my tests set a property which is further down the stack. This property would tell Hibernate to go ahead and use an in-memory backend, rather than a RDBMS. Now I can do everything that our other system has, without having to maintain it!

My tests will be running at in-memory speeds, and they will be testing the hibernate plumbing too (which makes them become more of integration tests, and some people will be angry at this point!).

Using a DB which has an in-memory option

Some good points have been made regarding just using HSQLDB as in-memory mode. That certainly works, but the tests still seem to take time bootstrapping the db in setUp().