Here's a programmer's view of what happens, using the example. As it happens, you can run it.

To use a suite fixture, change the TEST_RUNNER (you'll need to press Edit to see the textual form of this):

variable defined: TEST_RUNNER=fitlibrary.suiteFixture.FitLibraryServer

Now include a table in the SuiteSetUp page. Eg

ChatSuiteFixture

select or

complete

FitNesse runs this first for a suite. As ChatSuiteFixture is a subclass of SuiteFixture, it automatically registers itself with FitLibraryServer as the suite fixture.

The second table above results in a call to a method in SuiteFixture, which records the keywords to be selected in the storytests.

Then for each storytest, FitLibraryServer passes control to the suite fixture. As it is a subclass of DoFixture, it runs it in flow. So it runs the storytest until it finds that it's filtered out, or when it finds a DoFixture to run the rest. Eg, with:

keywords

complete,connect

chat

connect user

sarah

etc

Now the first table above results in a call to keywords(), a method that's defined in SuiteFixture. If the keywords hadn't matched, the storytest would be abandoned at this point and the first table marked as ignored.

Then the second table results in a call to chat(), a method defined in ChatSuiteFixture. This creates a specific DoFixture object and returns it (having passed any shared resources to it).

Because that's a DoFixture, the suite fixture passes control to it to execute the rest of the storytest, as usual. In the eg above, it runs the connect user table and those that follow, in the usual way.

Extra comments:

• This is analogous to the approach that DoFixture takes to go into flow
• The SuiteSetUp is used to get the suite fixture going at the start
• FitLibraryServer acts the same as FitServer when there is no suite fixture registered, so it's backwards compatible (and so FitServer could have the new code included so that it happens by default)
• A suite fixture can override keywords() and do whatever keyword processing it wants
• Other tables can be used in the SuiteSetUp to configure the suite fixture concerned (eg, with Spring or db info). As it's a DoFixture, it's trivial to add capability.
• As a DoFixture subclass, a SuiteFixture has setUp() and tearDown() methods called. So resources can be allocated and destroyed appropriately.
• Suite fixtures don't mix with fixture class names. When a fixture class name appears at the start of a storytest that use suite fixtures, it is simply treated as a DoFixture action. So |fit.ColumnFixture| will result in a call to fitDotColumnFixture(), if it exists.
• Suite fixtures could be easily nested by stacking their registration/deregistration
• This approach suffers from being added to an existing execution model, as with DoFixture flow. And so it can be confusing to people who are used to the current system (as happens initially with DoFixture). But in time, I'm sure that it can be incorporated cleanly.

Once it's clear that suite fixtures are going ahead, I'll put together a tutorial on getting started with them, as well as the steps involved in taking existing storytests and moving to this approach.

It's easy to switch over if you:

• Use SetUp pages for at least the first table of a set of storytests; and
• Don't mention fixture class names elsewhere