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

Tue, 06 Apr 2004

Fit extension: the StepFixture

I've been reviewing a forthcoming book on FIT, so I've been thinking about it a lot. Hence this blog category. I'm going to spew forth both some extensions to FIT and some stylistic quirks I've developed. I hope they'll provoke some blogospheric or wikispheric talk - or at least pointers to place where that talk's already happening.

Since a lot of my examples will involve my StepFixture, I'll talk about that first. (You can get it here. It has both my source and a jar file containing StepFixture plus the standard FIT fixtures.)

StepFixture is my alternative to ActionFixture.

ActionFixture depends on three keywords: enter, press, and check. The first two ask you to model your application as a device with a GUI-ish interface. My first difficulty with ActionFixture is that I'm afraid people will think the FIT tests should test through the actual GUI, though I know this is not Ward's intention. He would prefer the tests to bypass the GUI and test the business logic directly. The pretend device interface is just a convenient way to think about performing a series of steps. Still - to be overbearingly paternalistic about it - I think it's an "attractive nuisance."

I think that the problem could be alleviated by using cause as a synonym for press. Then you "probe the device" by entering data, entering data, ..., entering data, then causing some action. That's easily done by adding this code to ActionFixture.java:

    public void cause() throws Exception {
        press();
    }

I think long sequences like that are hard to read. I would rather see this kind of terseness:

It might be objected that this looks too much like a program's method call; that non-programmers will find the device model more friendly. I have experience showing StepFixture tests to only two Customers, but neither of them has seemed to have problems with the format.

Notice that, whereas press describes a method with no arguments, new case takes several. I've occasionally found it useful to have methods with the same name but different signatures. The following is a bit of a test that describes how sometimes the owner of an animal being treated doesn't pay all the charges. If a clinician does extra work for teaching or research purposes, the veterinary clinic will pick up part of the charge.

It might seem that it would be better to always have charge take both the amount and the entity-being-charged. But consider: there were already a bunch of tests that used the one-argument form. It would have been a hassle to change them. Moreover, we'd already established a vocabulary where charge 100 meant "charge the normal payer" - I want to build a vocabulary, not always be revising it.

I've also found arguments to be useful with the check keyword. For example, after the above, I might use these check statements:

They invoke, respectively, these methods:

    public int balance()...
    public int balance(String payer)...

So the expected value is always the last non-blank cell in the row. (That's a little awkward - I kind of wish they all lined up.)

Sometimes the use of arguments on check isn't necessary, but I find it more pleasing. (I think text that exists to promote conversation - as customer-facing tests do - should be pleasing to the eye.) For example, these check who does what how often:

There's no particular reason for "student does" and "soap" to be in separate cells, but I find the vertical alignment makes the set of checks easier to scan.

The FIT ActionFixture has the test explicitly start an application. I found myself drawn to a "FIT-first" style of coding, in which I started building the application within the fixture, factoring out pieces as it became convenient. So I did away with start. Nevertheless, an important part of FIT is the ability to have a test that includes more than one kind of table. So state has to persist across tables. As with the ActionFixture, that happens automatically with the StepFixture. If you want to start fresh, you use restart in the table:

That clears out all state and starts you with a new object. I'm not sure I like that, so...

Most of my tests have been a single StepFixture. So what I've found myself doing is having two subclasses of it for an app. The "AppFixture" fixture starts fresh. The "ContinuedAppFixture" signals that the current table is a continuation of a previous one. So a multi-table test looks like this:

... another type of table ...

In the code, the ContinuedAnimalProgressFixture is derived from StepFixture:

  public class ContinuedAnimalProgressFixture extends fit.StepFixture {
      private Case myCase;
      static public Accountant accountant; // Used by other fixtures
      protected Clinic clinic;
      ...

      public void newCase(String animal, String owner) {
        ...
      }

      public void diagnosis(String diagnosis) {
        ...
      }
  }

AnimalProgressFixture extends ContinuedAnimalProgressFixture, but reinitializes things:

  public class AnimalProgressFixture extends ContinuedAnimalProgressFixture {
      public AnimalProgressFixture() {
          super();
          restart();
          accountant = new Accountant();
          clinic = new Clinic(accountant);
      }
  }

I'm not sure I like that either.

If you want to use StepFixture and need more help, let me know.

## Posted at 20:35 in category /fit [permalink] [top]