Field Guide To Fixtures


This guide identifies the distinguishing features of the three primary kinds of fixtures so that you can easily tell them apart. If you would rather just observe fixtures, there are captive examples of each species cited in ColumnFixture, RowFixture and ActionFixture.


Column Fixture (Fixturous Logicus)

The ColumnFixture preys on business logic. It favors smaller functions that can be setup with a few columns of data and then tested with a few more columns of expected results.

Fields & Methods: Column fixtures implement fields and methods that the column fixture finds by reflection.

Variations: ColumnFixture is always subclassed to add fields and methods. A given subclass might implement more fielss or methods than need in any given table. Many tables can use the same subclass with different selections and arrangements of columns.

Young: Column fixtues may spawn domain objects for each row or even each method. Or they may not. Domain objects can easily outlive a single column fixture. One domain object might even serve all Column fixtures in the document.


Row Fixture (Fixturous Recordus)

The RowFixture gathers domain objects which it organizes and inspects. The row fixture is the only fixture that reflects directly on domain objects. All others reflect on themselves or their kind.

Fields & Methods: The row fixture's fields and methods are like those of the column fixture except that fields are read, not written. The row fixture considers the left side columns to be keys for sorting with the left most primary.

Variations: Row fixtures are always subclasses that vary by what kind of rows they get and where they get them. Field and column names are as varied as the domain objects they find.

Young: The row fixture creates or retrieves the objects that it inspects. The method getTargetType describes the young; the method query gets them.


Action Fixture (Fixturous Interactous)

The ActionFixture attacks the GUI facing parts of the domain model. It spawns and manages additional little fixtures for each "screen" the model expects.

Fields & Methods: The action fixture is the only one (other than some PrimitiveFixture) to not look at column headings for field and method names. Rather, the first column names methods of the action fixture itself, while the second column names additional fixtures (the screens) and methods on them. Action fixtues reflect on methods only, never fields.

Variations: Variation of the action fixture itself is rare and occures only when the basic actions, start, enter, check, and press prove insufficient.

Young: The action fixture spawns more fixtures from its start method. These fixture may spawn one or more domain objects as is the practice of the real screens they imitate.

 

Last edited September 14, 2002
Return to WelcomeVisitors