Can we run Fitnesse tests intehrating with JBoss server running in another JVM? I know Fitnesse runs on its own JVM. Is the command pattern is the solution?

1. Run JBoss separately with support for remoting, pass the InitialContext into fixtures somehow in the setup (perhaps using a fixture to set it up or a system property).
2. re-engineer the application so that you can test objects in isolation without JBoss. if you use spring or something like that to wire up things, you might be able to execute the tests just with spring and without JBoss.
3. use the idea I applied to run fitnesse within spring transactions to create a new test runner, which you will be able to use from !define COMMAND_PATTERN. Your test runner should kick off JBoss and wire-up fixtures to the InitialContext correctly, this should allow fixtures to grab the right objects by remoting. See the example source code for transactional wrappers, and instead of starting up spring and rolling back transactions, you might want to start and stop JBoss. Note that this code is quite old and I do not know if it is compatible with the latest version of fitnesse
4. use the JUnit runner that is built in with fitnesse and combine it with JUnitEE2 or Apache Cactus, so that you get a web page to kick off JUnit tests, which will in turn kick off fitnesse tests within a container. This setup requires the least amount of code change, but does not allow you to use a fitnesse user interface any more to execute the tests (you can still use it to write and manage the tests). I’ve done this setup for a few clients and it’s not ideal, but allows your fitnesse tests to be executed within a J2EE container.

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.