Exploration Through ExampleExample-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
|
Tue, 06 Apr 2004Fit 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:
I think that the problem could be alleviated by using public void cause() throws Exception { press(); }But my second difficulty is that the tests are verbose:
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
It might seem that it would be better to always
have
I've also found arguments to be useful with the
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
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
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. |
|