It was kicked off by an interview of Ward Cunningham and James Shore on Hanselminutes where Ward & James were asked whether Fit was dead.

Bob Martin first reacted on Twitter by pointing out that, at any rate, “FitNesse is thriving”, along with Slim, a new system that can be used by Fitnesse as an engine to run the test tables.

Michael Feathers replied that, in his view, Fit was more appropriate as a seed for other works: “Take it, grow it locally, and never commit back.” This seems confirmed by James Shore, a former leader of the Fit project (and a successor to Ward in that role): “Fit core was intentionally resistant to change [...] from an organizational perspective”

Interestingly, James believes that both Fit and Fitnesse have “similar flaws, which could be solved by another approach”:

• “Fit flaw #1: maintenance. HTML is hard to maintain and refactor.”
• “Fit flaw #2: Customers. Customers don’t generate the documents, and that was the whole idea.”
• “Fit flaw #3: Programmers. Fit loves domain models and Whole Value. Most programmers don’t. Impedance mismatch.”

This last point is actually seen as a benefit by J.B. Rainberger: “Similar to JUnit, Fit puts positive pressure on programmers. [That said] TDD informs design, but many use JUnit for testing. Fit informs feature design, but many use Fit for testing.” James agrees: “Fit drives the design of the domain layer just as TDD drives separation of concerns.”

JB & James both note that, regardless of the tool itself, they “continue to succeed collaborating with customers with Fit’s table format”, typically by “collaborating with examples on a whiteboard”.

Possibly, the biggest shortcoming (as stated by James & Ward during the interview, but also in twitter by Brian Marick: “I can’t offhand think of any product owner who wrote tests in any format”) is that the assumption that business people would write the tables was flawed. A view not shared by Keith Braithwaite “I’ve had actual users write tests in tables in excel with success”. JB, for one, prefers “Customers help write docs”, reformulated by Elisabeth Hendrickson as “Business stakeholders & implementation team collaborate on articulating expectations.”

Finally, several people including Willem van den Ende pointed to BDD and especially to Cucumber as a better implementation of the same ideas “Cucumber given/when/then steps flow naturally for me, FIT- style tables are optional, I add them later if needed.”

For more details see the following links:

• Details by James Shore on how to use Fit (or not)
• Michael Feathers’ opinion on the code that makes the Java implementation of Fit
• The interview of Ward Cunningham and James Shore on Hanselminutes

In the release he did a couple of days ago, he added 2 interesting things:

• one is a format tool that helps giving a more readable view of your tables, in editing mode; unfortunately, your edit panel must be using a fixed-size font (which it is not the case by default on my system)
• the most interesting addition, though, is the support of SCM tools to store wiki pages

There are two ways to configure a SCM tool.

The first is to specify it on the command line:

  java -DCM_SYSTEM=package.to.AParticularCmSystemIntegrationClass -jar fitnesse.jar

The second is to specify in a high-level page on your hierarchy of pages:

  !define CM_SYSTEM {com.project.fitnesse.OurSvnSystem me/my_password /cm/myRespository}

This one is interesting, because it allows you to have different configurations for different hierarchies of pages (typically one for each different projects, or even for different versions of the same project).

The bad news, though, is that the CM System Integration class in question is not provided by default, though I’m sure that in time there will be all sorts of appropriate integration classes provided with Fitnesse. But that’s not the case so far (except for an example made to connect to Git — not sure how generic it is). That said, it does seem quite easy to implement that class (you basically need to implement calls to the command line in Java).

You might want to download the Fitnesse release and check out the FitNesse.UserGuide.SourceCodeControl page. As often with Fitnesse, the website does not have the latest details.

Not content with the videos on Slim, he has just produced another one showing how to do basic staff with Hudson. And by the sound of his voice, he is sold!

Inteerstingly, he compares the simple startup process of Hudson to the one in Fitnesse: just download and run.

Update (14/12/08): Uncle Bob has actually put online his Hudson install

Data types in Slim are simple. They can only be Strings and Lists, though it is entirely possible for fixtures to actually get integers.

A list looks like this:

[1, 2, 0.5]

Note the brackets. Also, note the space between the comas and the following value. This is important, as the comparaison will actually be made between the exact string specified in the table, and the String representation of the List returned by the fixture. Hence, the format in toString() is important.

There are two majors things to learn in it:

• approximate equals
• ranges

The ~= sign means “approximately equals to”, and depends on the number of decimals; for example,

~=1.3

in a cell will work for any value between 1.2 and 1.4.

A range allows Slim to accept results between boundaries. For example, put something like

1<_<8

in a cell and all values between 1 and 8 will be considered valid. This is something that some versions of Fit could do, but not all. With Slim, all versions of Slim will support this (since it will be evaluated on the Fitnesse side).

Last thing: Fitnesse contains a rather powerful expression evaluator that is not specific to Slim or Fit.
For example:

!define TIMES {1000}
|${=5*${TIMES}=}|

You can combine this construct with the range, and have something like this in your cell:

${=5*${TIMES}=}<_<${=6*${TIMES}=}

which will appear as

5000<_<6000

when viewing your wiki page.

Finally, you might want to watch out for the coming minor release of Fitnesse.

Well, Uncle Bob is coming back with Slim, an extension of Fitnesse he has been working on since August 2008, as his followers on Twitter know. It has been released in the latest version of Fitnesse a few days ago.

Simply put, Slim (Simple List Invocation Method) is an alternative to Fit, quite simpler to implement and to use, and integrated with Fitnesse.

The big thing with Slim, for us mere users, is that it calls POJOs. No need to inherit from Fit-specific classes anymore! (something that GreenPepper has had for a long time) You will just have to implement some methods with particular names, depending on the type of fixture you use.

The fixtures that are available are familiar ones:

• Decision Table, the equivalent of Column Fixture, with input columns and output columns
• Query Table, the equivalent of Row Fixture; interestingly, its method query() now returns a List of Lists of Lists (!) instead of an Object[]  table
• Script Table, the equivalent of Do Fixture in FitLibrary; it also shares many caracteristics with ActionFixture
• finally, Table Table is the way for you to write any arbitrary fixture

Other enhancements include:

• variables in fixtures can stay private; no need for them to be public anymore; setter methods are required instead. Not a big deal in my view, but something that beginners were often complaining about
• error messages are clearer in Fitnesse, typically when classes or methods cannot be found in the fixtures
• as a side effect of an evolution of Fitnesse made necessary by Slim, it is now possible to run tests in differents JVMs
• Slim is much simpler to implement than Fit is; this is supposed to make ports of it to other languages much easier, more stable, and more consistent (some implementations of Fit do not have the exact same features as others)
• it should also be possible to write tests without tables (with updates of Slim), which was very difficult with Fit, because of all these implementations; I want to see things like the plain text tests in TextTest !

Convinced? Then the next step for you is to look at the tutorial video Bob Martin did yesterday.

Me, I think this is a great enhancement, and one of the biggest news in the TDR Tools world this year. With Bob Martin’s influence, there is no doubt it will pick up steam quickly.

Here is a look to the RichNesse editor (note the button bar on top)

Compare to the old editor:

There are four features that make the difference:

• Undo/Redo; yep, it seems that everything you do while under the editor can be undone
• Search and Replace! That was not in the basic editor. So when you wanted to change the name of a variable, you had to copy & paste into a text editor, and copy back again. It’s now built in!
• one button to insert a whole column: saves tons of keystrikes
• a button that redirects to the upload section of Fitnesse; that was not in the basic editor.

Unfortunately, I spotted a number of limitations. None of them are very serious, though:

• Some formattings very specific to Fitnesse such as collapsible sections are not available yet.
• The Copy and Cut buttons did not work and Paste behave curiously. The message I got was that my ‘browser security settings don’t permit the editor to automatically execute cutting operations.’ Of course, Ctrl-C, Ctrl-X and Ctrl-V still work perfectly.
• Integration with Fitnesse is not perfect. For example, if you create a table, the wizard will allow to enter a ‘caption’. Unfortunately, this caption will mess up the display and prevent the table from being properly interpreted as a fixture.
• The editor that opens when you first create a page is the basic Fitnesse editor. This is not a big deal: you can always save the empty page and reopen it again.

Another feature that I’d like to see, but that will no doubt be tricky to implement, would be some kind of search & insert feature for links to other pages. Fitnesse is rather complex on this, especially since it supports hierarchical pages (a concept not usually found on wikis). It’d be cool to be able to search for a page, and then specify whether you want to link to it as a sub-page, or an absolute URL, or even as a SymbolicLink.

All in all, it is a very useful addon to FitNesse, one that I now systematically install. No doubt that lots remain to be done, but come join the fun now, it is already worth it!

Note the RichNesse button on the left when viewing a page; the Edit button is still available

And that is: remember to remove import tables in your Setup pages.

The way DoFixtures work, is that they put the test into a ‘flow’ mode. However, that works only if the DoFixture is the first table in the page. Even the harmless import table should be removed. Which is not a big deal, since you normally have few additional fixtures in the page. However, it also means that you cannot use a Setup page with an import table to define default packages.

One thing I don’t like about FitLibrary, is that it does not have its own website (or rather, it used to, on SourceForge, but all pages have been removed), so you lack a reference documentation. What you end up doing, is using the FitLibrary that comes with Fitnesse, only to realize that many comments on the Internet refer to a more recent version. And you have to download the latest version of Fitlibrary (an its documentation)  anyway.