Action Fixture


An action fixture interprets rows as a sequence of commands to be performed in order. The MusicExample, NetworkExample and TimeClockExample use action fixtures.

See also RowFixture, ColumnFixture or the FieldGuideToFixtures.

An action fixture interprets tables for which the first column contains one of a small number of commands. Subsequent columns contain values interpreted by the particular command. The generic action fixture offers only four commands, but subclasses may extend this set.

  • start aClass -- Subsequent commands are directed to an instance of aClass. This is similar to navigating to a particular GUI screen.

  • enter aMethod anArgument -- Invoke aMethod with anArgument (of type determined by aMethod.) This is similar to entering values into GUI fields.

  • press aMethod -- Invoke aMethod with no arguments. This is similar to pressing a GUI button.

  • check aMethod aValue -- Invoke aMethod with no arguments. Compare the returned value with aValue. This is similar to reading values from a GUI screen.

See source.

Actions are delegated to aditional fixtures (actors). See source for the actor used in the NetworkExample.

Q: It seems like the actions are always in column one. Is this a requirement of the input format?

A: Actually ActionFixture supports a "tripple dispatch" where each dispatch is closer to the domain. Imagine the row:

enter transaction deposit

Column 1 is about the interaction paradigm, i.e. panels, fields and buttons. Column 2 is about the particular panels, fields and buttons that the application under test supports, while Column 3 is about things that the application itself must interpret. That is what we are ultimately testing.


Last edited March 4, 2003
Return to WelcomeVisitors