Transactional Spring/Slim test runner

Here’s an implementation of the Slim test runner for Fitnesse that wraps all tests into spring transactions and rolls back on the end of each test, to make data-driven tests instantly repeatable with minimal code and no configuration changes in the fixtures or the Spring context.


  1. Include the transactionalrunner-1.0.2.jar in your classpath
  2. Include Spring, all other dependencies etc in your classpath
  3. Have your spring context file accessible (ideally in the classpath or on the file system). Make sure to have a transaction manager defined there and the tx:annotation-driven tag set up correctly to link to the transaction manager
  4. Set the test runner configuration in your test suite (it’s not going to work if it is in SetUp):
    !define TEST_SYSTEM {slim} 
    !define TEST_RUNNER {info.fitnesse.TransactionalSlimService}
    !define COMMAND_PATTERN {java  -Dspring.context=classpath:spring.xml -cp %p %m -v}

    the -v on the end is optional and causes lots of debug messages to be printed out. You should see “rolling back now” after every test in the suite. You can set the location of your basic spring context file by defining the spring.context parameter as in the example above. Use standard spring locator prefixes for that.

  5. Change your fixtures to use info.fitnesse.FitnesseSpringContext.getInstance() as the spring context rather than loading it yourself. You can use autowirable bean factories from there on.
  6. Run your tests as nornal. The spring transaction context will roll back after each test

How it works

The test runner loads your spring context file (from the spring.context system variable) and then injects an additional test runner bean into the context, making it available through the static info.fitnesse.FitNesseSpringContext instance.

Instead of directly executing instructions in processTheInstructions(String instructions), this test runner delegates the call to a Spring bean which is transactional, so the call passes the declarative transactional boundary for each test. The Spring bean throws an exception that causes the transaction to roll back on the end of each test and the test runner catches and ignores that exception. This uses the same idea as in The magic ingredient for the FitNesse, Spring and Hibernate TDD soup, but applied to Slim. (hint: you can use the same jar to run normal fitnesse tests, just change TEST_SYSTEM to FIT and TEST_RUNNER to info.fitnesse.TransactionalFitServer).

The rollback bean is loaded from an spring context file embedded in transactionalrunner.jar so you are not required to change anything within your spring context. The only possible problem is if there is already a bean called “rollbackBean” defined there. The embedded context doesn’t have any transaction managers or anything else defined, so it expects all that to be defined outside.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your Tests. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

How to get more value out of user stories

Impact Mapping

4 thoughts on “Transactional Spring/Slim test runner

  1. not at the moment. you can create a spring config file that just includes the rest. or, you can grab the source, tweak it and enjoy.

  2. Do you have an example test suite that uses this? I’m very new to fitnesse and I’m trying to figure out how to use this in a suite..

    Many Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *