… The only issues still open are, how to test for a whole bunch of browser
environments and how to reset my test database before each run of the test
suite for each environment.

You can use FitNesse test suites with symbolic links and different setups (eg firefox suite uses all tests from IE suite using a symbolic link, see the section on Symbolic Links from my FitNesse book). All browser
configuration can be in the SetUp page, which will be overridden by the firefox suite. So the configuration should be something such as:

• AllTests
  • IeSuite
    • SetUp (IE configuration)
    • BrowserTests (actual tests)
      • TestOne…
  • FirefoxSuite
    • SetUp (FF configuration)
    • BrowserTests (symlink to -> .AllTests.IeSuite.BrowserTests)

FitNesse will supply the Firefox SetUp to all the imported pages in the FirefoxSuite, and the IE configuration to all the test pages in the IE suite. As long as all browser specific configuration is stored there, you will be able to run tests against different environments and maintain it only in a single place.

In terms of database resets, the best thing to do is to make tests data agnostic, so that you can run them over and over on the same database. this might take a bit of programming around database IDs and sequences, but is the best possible thing to do. You can also add a database reset or reload to a SuiteSetUp page to each suite, which will execute only once before the entire suite. Put that as well into the imported suite (BrowserTests) and it will be called before each browser suite even if you execute all the tests at the same time.

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.

To enable this feature, override the default test listener in the JUnitHelper instance you use for test runs (third constructor argument), and supply a JUnitXMLTestListener instance passing the folder where you want the XML files in the constructor argument. For example:

 String htmlOutputDir=new File(System.getProperty("java.io.tmpdir"),
                                  "fitnesse").getAbsolutePath();
  String xmlOutputDir=new File(System.getProperty("java.io.tmpdir"),
                                   "fitnesse-xml").getAbsolutePath();
  String fitNesseRootDir=".";
  JUnitXMLTestListener xmlTestListener=new JUnitXMLTestListener(xmlOutputDir);
  JUnitHelper helper =
      new JUnitHelper(fitNesseRootDir,htmlOutputDir,xmlTestListener);
    helper.assertTestPasses(".....");
 

Grab the source from my github repository. Also, check out the full example.

What’s new in this version?

Since the book was originally released, both FitNesse and the .NET FIT test runner were improved significantly. All the examples in this book are now updated to be compatible with the latest releases of FitNesse (20091121) and FitSharp (1.4). I re-wrote parts that are no longer applicable to the new FitSharp test runner, especially around Cell Operators. In a classic example of self-inflicted scope creep, I also wrote a new chapter on using domain objects directly.

I also changed the tool used for assembling the book. Instead of Apache FOP, I used XEP which will hopefully make the layout a bit better. Fonts (especially the code font) were also changed to make the book easier to read.

What about the paperback

I will make the paperback available soon. At the moment, the second edition is only available online.

• JUnit Suite Runner (@RunWith) that prints fitnesse test names in JUnit reports (thanks to Johannes Link)
• Test names in suite results are now now hyperlinks to test outputs (thanks to Björn Beskow)
• Compatibility with latest FitNesse version (20090513)

For more information, examples and download links see http://fitnesse.info/trinidad