Declarative transactions in Spring and Hibernate make programming enterprise applications much easier, but they also make integrated database tests a bit tricky. Crossing the transaction boundary between fixtures and services will cause data changes to become permanent, which makes tests non-repeatable and harder to maintain. I’ve finally found good solution for this problem — it is a bit dirty, but very effective.

The trick is based on the fact that FitNesse does not execute FIT in-process, but as an external program in order to allow test runners for languages like C# and Python to be plugged in.

We can use this feature to supply a different Java test runner, which will be injected into the Spring context straight from the start. We can mark the entry point as @Transactional, so no matter how many fixtures are instantiated and how ever they use the service layer, the calls will never cross the transaction boundary and require the transaction to commit. On the end, the test runner just has to roll back the active transaction and everything that the test changed will simply disappear.

This solution is totally non-intrusive, and automatically works for all fixtures. There is no need to replicate transaction management code all over the test suites. No special fixture code is required in fixtures or services, and it does not matter whether the page is in flow mode or works with standalone fixtures. No special SetUp or TearDown pages are required.

Implementing it, however, turned out to be tricky. That is why I said that the solution is a bit dirty. The FIT server class was not written with such use in mind (which is no surprise, really). But the ugly part is encapsulated and hidden from the end users, so it works good enough. You can get the code from http://gojko.net/2008/01/22/spring-rollback/