I just wanted your opinion on SLIM as opposed to standard FIT/Fitnesse. Are there things that can only be done via the FIT/Fitnesse route that cannot be done via SLIM? So for acceptance tests and integration tests can I just use SLIM?

We want to exploit the BDD abilities of Scenario tables in SLIM. Ideally I would like to use SLIM to undertake all kinds of tests. I assume it has all the same capabilities? Are there any issues?

On the face of it, SLIM seems to be the preferred way forward for new FitNesse implementations as it is being actively developed and maintained by the same folks who develop FitNesse. FIT is a bit of an orphan at the moment, Rick Mugridge and I were talking about taking over that integration and enhancing it.

In terms of features, SLIM gives you better compatibility across platforms because a lot of the test system responsibility has been taken over by FitNesse itself (parsing HTML, deciding how to interpret a table, storing and reading symbol values). Watch this video for more information about the differences in responsibilities.

On the other hand, because of the way SLIM works, fitlibrary flow-mode interaction is practically impossible. Most of my clients still use flow mode tests as that is a great way to write and maintain a very thin fixture layer for complex tests.

SLIM also allows you to use Scenario tables, as you mentioned. Scenario tables give testers a lot more power as they can script multi-step execution and compose lower level fixtures into higher level tables, without involving developers to do the same in fixtures. Depending on your environment and team, this might or might not make sense. For covering and existing system with regression tests, it probably does. For using acceptance tests as a guide for development, beware of overdoing it. I am very concerned about long-term maintenance costs of such tests. What happens in this case is that people are effectively programming with tables – doing the same in code would allow you to benefit from IDE support for refactoring, file management and all sorts of other things that make IDEs useful. You lose all that by using scenario tables in order to make testers a bit more independent. I would rather suggest training the testers some basic coding skills so that they can write fixtures.

Here is the video from my recent presentation “SLIM and the future of FitNesse”. In this talk, I introduce SLIM, the new FitNesse test runner, compare it to FIT and demonstrate its basic features. You can also download the slides

I’m covering QCon in detail on this blog. See other news and reviews from the conference

FitNesse.NET tips and tricks

The talk will cover best practices, common pitfalls and some advanced techniques for using FitNesse in the .NET environment that will help you save time and effort when writing and automating acceptance tests. This is a session for .NET developers with some previous exposure to FitNesse.

Skills Matter, Feb 17th: click here to register

Slim – The future of FitNesse

This talk will introduce Slim, the most important upgrade to FitNesse in years. Slim is the new test runner which promises to bring platform interoperability, easier integration, a much simpler programming model and lots of small helpers that will allow us to write and maintain executable specifications and acceptance tests easier. This is a session for .NET and Java developers. Some prior exposure to FitNesse and FIT would be beneficial, but not required.

QCon London, March 13th more info

Repeated at skills matter on April 2nd: click here to register

The two events at skills matter are free but up-front registration is required for capacity planning.

• binaries (compiled against spring 2.5.5 and fitnesse 20090112)
• source code

Usage

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.