Fri, 11 Feb 2005
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
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]
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