Unitils is an open source library aimed at making unit testing easy and maintainable. Unitils builds further on existing libraries like DBUnit and EasyMock and integrates with JUnit and TestNG .

Unitils provides general asserion utilities, support for database testing, support for testing with mock objects and offers integration with Spring , Hibernate and the Java Persistence API (JPA). It has been designed to offer these services to unit tests in a very configurable and loosely coupled way. As a result, services can be added and extended very easily.

What particularly caught my attention was the support they’ve included for transactional test cases. By transactional, I mean test cases that will automatically cleanup after themselves. Simply include a @Transactional and you’re rocking.

In the past, we’ve rolled this capability ourselves with varying degrees of success. It’s easy to support rolling back of inserts but somewhat difficult to handle rolling back of deletes and other data mutations.

I’m just in the process of kicking off some new product development (actually, we’re one week into it but who’s counting) and general infrastructure (testing included) is something forefront on our minds.

For starters, we’ve got Cobertura and Selenium integrated into our build. General unit is covered with TestNG with Seam components integration tested using SeamTest/Embedded JBoss. Everything short of the Selenium tests are hitting freshly initialized in-memory databases.

It might be worth considering something like Unitils at this stage rather than building out our own tooling to accomplish much the same thing.

Everything was going well, caught some of the low hanging fruit (running things on the EDT, not batching requests, retrieving too much data, etc) but ran into a brick wall when trying to do a contains (%VALUE%) query on a table with 100k records joined to a table with 75million records.

ie) SELECT tableA.* from TableA tableA join TableB tableB on tableA.fk = tableB.pk WHERE tableB.sequence LIKE ‘%VALUE%’;

The explain plan (the DB in this instance was Oracle) didn’t look bad when doing the query on TableB, but when joining to TableA it absolutely blew up.

To cut to the chase here, I ended up creating a contextual index on the column using the Oracle Text package that was installed along with the DB. The explain plan complexity droped like a stone and things were good again.

In the end, a rather simple solution to a problem that was quite significant in our books. I don’t know enough about the Oracle Text package to say whether its a good thing or not. We’re doing context-based searches on long strings of characters, not the documents for which it appears to have been defined. Already I’ve found that a search for 3 characters takes magnitudes amount of time longer than a search for 4 characters (although this makes sense).

What I didn’t try was creating a straight index on the column but from people I talked to and what I read that wouldn’t have helped in the case of the %%. We had another case where an UPPER() function call was causing it to miss an index, but I believe in that case I should be able to create a index on the UPPER’d result or perhaps another column in the table and a trigger that always UPPER()’s the result in it.

Back to my regularly scheduled life as a developer, too much DB work for one day.