FixtureScripts.MultipleExecutionStrategy (enum)

How to handle fixture scripts that are submitted to be executed more than once.

Note that this is a FixtureScripts#getMultipleExecutionStrategy() global setting of the FixtureScripts service; there isn’t (currently) any way to mix-and-match fixture scripts that are written with differing semantics in mind. Ideally it should be the responsibility of the fixture script itself to determine whether it should be run. As a partial solution to this, the

API

FixtureScripts_MultipleExecutionStrategy.java

enum MultipleExecutionStrategy {
  EXECUTE_ONCE_BY_CLASS     (1)
  EXECUTE_ONCE_BY_VALUE     (2)
  EXECUTE     (3)
  boolean isExecuteOnceByClass()
  boolean isExecuteOnceByValue()
  boolean isExecute()
}

1	EXECUTE_ONCE_BY_CLASS Any given fixture script (or more precisely, any fixture script instance for a particular fixture script class) can only be run once.
2	EXECUTE_ONCE_BY_VALUE Any given fixture script can only be run once, where the check to determine if a fixture script has already been run is performed using value semantics.
3	EXECUTE Allow fixture scripts to run as requested.

Members

EXECUTE_ONCE_BY_CLASS

Any given fixture script (or more precisely, any fixture script instance for a particular fixture script class) can only be run once.

This strategy represents the original design of fixture scripts service. Specifically, it allows an arbitrary graph of fixture scripts (eg A → B → C, A → B → D, A → C → D) to be created each specifying its dependencies, and without having to worry or co-ordinate whether those prerequisite fixture scripts have already been run.

The most obvious example is a global teardown script; every fixture script can require this to be called, but it will only be run once.

Note that this strategy treats fixture scripts as combining both the 'how' (which business action(s) to call) and the also the 'what' (what the arguments are to those actions).

EXECUTE_ONCE_BY_VALUE

Any given fixture script can only be run once, where the check to determine if a fixture script has already been run is performed using value semantics.

This strategy is a half-way house between the #EXECUTE_ONCE_BY_VALUE and #EXECUTE strategies, where we want to prevent a fixture from running more than once, where by "fixture" we mean the 'what' - the data to be loaded up; the 'how' is unimportant.

This strategy was introduced in order to better support the ExcelFixture fixture script (provided by the (non-ASF) Causeway Addons’Excel module. The ExcelFixture takes an Excel spreadsheet as the 'what' and loads up each row. So the 'how' is re-usable (therefore the #EXECUTE_ONCE_BY_CLASS doesn’t apply) on the other hand we don’t want the 'what' to be loaded more than once (so the #EXECUTE strategy doesn’t apply either). The solution is for ExcelFixture to have value semantics (a digest of the spreadsheet argument).

EXECUTE

Allow fixture scripts to run as requested.

This strategy is conceptually the simplest; all fixtures are run as requested. However, it is then the responsibility of the programmer to ensure that fixtures do not interfere with each other. For example, if fixture A calls fixture B which calls teardown, and fixture A also calls fixture C that itself calls teardown, then fixture B’s setup will get removed.

The workaround to the teardown issue is of course to call the teardown fixture only once in the test itself; however even then this strategy cannot cope with arbitrary graphs of fixtures. The solution is for the fixture list to be flat, one level high.