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:

charge 50 dollars against account 89-64P
schedule 10 dollar payment monthly from checking

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:

  void chargeDollarsAgainstAccount(int dollars, String account)
  void scheduleDollarPaymentFrom(int dollars, String frequency, String source)

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:

com.exampler.writer.fixtures.TemplateCreator letter template
field default
Salutation To whom it may concern:
Closing Respectfully yours,

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

create template named letter template with these fields
field default
Salutation To whom it may concern:
Closing Respectfully yours,

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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo