Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Fri, 11 Feb 2005

Rick Mugridge rocks

This week I traveled to a client who was using FitNesse, the Wiki-enabled version of Fit. They were using ActionFicture, which I've never been fond of. Earlier I'd replaced it with my own StepFixture, but I knew Rick Mugridge had a new type of fixture called the DoFixture, so I prevailed upon him to let me take a copy with me.

I'm in the first flush of enthusiasm, but I think it's a big step beyond StepFixture and similar fixtures. When I read about it, I thought it was an improvement, but I didn't appreciate how well it suits my goals for acceptance tests. Here's an example:

I strongly prefer Fit tests to be business-facing, written in the language of the business instead of the language of the implementation. Because the rows can be read as sentences, there's less of a translation gap between what a product owner says about the desired product and the way the tests are written. That seems to help keep them business-facing.

Moreover, it may be easier to envision a succession of tests as a progressive explanation. If reading the tests is supposed to help you understand a feature, the tests should start with the simple cases and build up progressively to the complicated ones. There's a tendency in test writing to set up an enormously complicated state once, then execute a series of actions and checks. I think that's bad for two reasons. One is that the test becomes hard to understand. The other is that it gives the programmer no obvious place to grab hold and get started. With a series of progressive tests, the programmer, product owner, and tester can devise a few simple cases right away. Then the programmer can launch off into coding while the product owner and tester mull over the more complicated cases. The programmer doesn't face the choice between coding without a concrete goal or waiting around for something to do.

Another nice feature of the DoFixture is the way it wraps other fixtures. Before explaining that, here's how a DoFixture would handle the above table. The table translates into calls to these two methods on the DoFixture:

The DoFixture doesn't care much about table boundaries. It can run any number of tables in succession. But when it encounters the first row of a table, it does a special check. If the row begins with a fixture name, it handles it in the regular Fit style. But if it's a method that returns a fixture instance, the DoFixture recursively uses that instance to process the table, returning to the DoFixture after the table's done.

One practical result of that is that a table that once looked like this:

... can now have a first row with the same effect but a different style:

That doesn't seem like such a big deal, but the difference betweeen a DoFixture style page and a standard Fit page is that there's only one mysterious technology-facing row that says something like com.exampler.writer.fixture.FixtureName. The visual appearance of the page is more pleasant, looks more like a document written for humans.

The DoFixture isn't in general release yet, I don't think, but it should be soon. Watch for it. Thanks, Rick.

P.S. There's one thing that I think Fit still needs to convert it from a tool for the test-infected visionary to a mainstream tool, and that's a Fit-specific editor. For example, if I were in "row-fixture mode", I'd want to type the above table like this:

[command to start a row fixture]
charge[tab]50[tab]dollars against account[tab]89-64P[return]
schedule[tab]10[tab]dollar payments[tab]monthly[tab]from[tab]checking[return]

The table would grow itself around the words I'm typing instead of my having to create it first. That would allow me to type the table quickly, instead of boring the product owner while I fiddle with table formatting. And the editor would take care of italicizing the keywords. (Although that's not required, I think it helps.) It might also touch up the table with the appropriate <colspan> attributes to keep it looking tidy. Oh, and it should support modifying tables so that changing the tests is as pleasant as changing the code in an editor like IDEA. And it would be cool if certain table refactorings (like "extract method" from DoFixture tables) also automagically refactored the underlying Java code. I ain't asking for much.

## Posted at 21:36 in category /fit [permalink] [top]