Action Fixture

The FIT ActionFixture, and the closely related TimedActionFixture, allow you to test workflow procedures, that is, components where actions have to be done in a sequential order. ActionFixture uses a machine metaphor: there is a widget where buttons are pressed, data entered in small pieces and results presented and checked. For an alternative way of handling workflow, see the FitLibrary's DoFixture.

The most common such component is, of course, the ubiquitous GUI. There are a number of very good discusions of issues involved in using FIT to test GUIs, including chapter 32 of the Fit book . Alistair Cockburn also includes FIT in his excellent Hexagonal (Ports and Adapters) Architecture article. It's well worth reading, if only for the alternative perspective on the more traditional layered architecture.

As in all fixtures, the first row contains one cell that specifies fit.ActionFixture. The rest of the table consists of rows which each have three columns. The first column contains one of four operations; the second and third columns contain data for the operation. For most of the operations, the second column contains the name of a field, method or property, and the third field contains data to be set or checked. An additional column can be used for comments.

There are four commands: start, enter, press and check. The start command loads the external fixture; the second cell in the row is the fixture name in the same form as if it headed a table. This command instantiates the named class. There is no data in the third cell.

The first ActionFixture must start with a start command. Subsequent ActionFixtures do not need a start command; they will inherit the actor from the previous ActionFixture invocation. The class named on the start command must contain the type information in its _typeDict dictionary. See the TypeAdapter writeup for how to create and populate this dictionary. This class also contains all of the fields, methods or properties named in the other commands.

The enter command is used to enter data. The second cell is the field, method or property name, the third cell is the data. This command uses a TypeAdapter to convert the input data to whatever form the method expects. This command is expected to return None.

The press command is used to press a button, invert the state of a checkbox or activate a menu command. It normally has no data. Radio button selections should be handled by the enter command. This command requires a method with no operands; it will not work with either a field or a property.

The check command is used to get information and check it.

Comments can be added to any row in a fourth column.

There is an interesting issue in designing actors to go with ActionFixture. Saving and restoring the previous actor has to be done by saving and restoring the actor attribute of the ActionFixture class. This can occasionally lead to an import loop, especially if one is using an ActionFixture subclass. Modules ActionFixtureUnderTest and AnotherActor in the fitLib.specify directory show how to use a callback mechanism so that the actors do not have to import the ActionFixture module. This is tied to the SwitchActor specification test in the fitLib.tests.FixtureSpecification.ActionFixture directory.

Tests expressed via ActionFixture tend to be quite tedious; the style sometimes obscures the fundamental issues being tested. One alternative to be considered is DoFixture. Another alternative is the table style shown in Section 11.1 of the Fit book.