How Scenario Execution works

This section explains the technical details of how a scenario gets executed.

Twist uses Spring to load and execute scenarios. The Spring container can be configured using the applicationContext-suite.xml and applicationContext-scenario.xml configuration files.

Please see http://static.springframework.org/spring/docs/2.5.x/reference/beans.html for details on configuring Spring.

Execution of a scenario

Scenarios are executed in a remote process. This ensures that Twist IDE is not influenced by errors or issues that may occur as part of running the scenario.

Setting up Application Contexts

The remote process that is executing the scenario(s) starts a Spring Container. Only one instance of the Spring container is created per launch. The Spring Container creates and uses two kinds of Application Contexts:
  1. One suite level context that is common to all the scenarios that are being executed. This context is created once and is common for each Scenario being executed in the launched process. This context is configurable using applicationContext-suite.xml
  2. Contexts that are specific to each scenario being executed. The Spring container will be re-initialized with such a new context for each Scenario being executed. This context is configurable using applicationContext-scenario.xml

The suite level context is loaded by searching for the file named applicationContext-suite.xml. This file can be overridden by specifying a new value for the System property suiteContext. So, if you specify a System property as suiteContext=foo.xml, foo.xml is the name of the file that Twist will search for loading suite level beans.

Similarly, scenario level beans can be used to specify a value for the property scenarioContext.

Executing scenario elements

The execution of the elements in a Scenario begins once the Spring container is initialized. Elements of the scenario get executed in sequential order.
Execution of Contexts
  • If Contexts are specified, they are invoked in the order they are specified.
  • The setUp method of each Context gets executed. The rest of the scenario gets executed.
  • The tearDown method of each Context gets executed after all elements and tables in the scenario get executed. Note that the tearDowns get executed in the reverse order.

    For example, if you have ContextA, ContextB then the execution order would be:

    setUp of ContextA
setUp of ContextB
                        
Elements in the scenario in sequential order
                        
tearDown of ContextB
tearDown of ContextA
  • Note that Contexts get executed even if the elements in the Scenario fail or throw an error.
Workflow Execution
  • Workflow steps are executed in the order they are specified in the Workflow. An instance of the underlying Fixture of the Workflow is created.
  • The methods corresponding to each Workflow step are executed sequentially.
Business Rules Table Execution
  • An instance of the underlying Fixture for the Business Rules Table is created. Rows in a Table are executed sequentially.
    For each row:
    • For each Input column, corresponding set methods are called on the underlying Fixture instance.
    • For each Assertion column, a method with the same name as the column is invoked on the underlying Fixture instance. The value returned is compared with the value specified in the table to determine pass/fail condition.

A fresh instance of the underlying Fixture is created for each executable element in a scenario. So, if you have the same Workflow repeating again in a scenario, Twist would be using a new instance each time. This holds true for Business Rules Table as well.

Handling errors and failures

Scenario execution does not stop on any failures. Twist identifies all org.junit.Assert failures and java.lang.AssertionErrors as test failures.

If execution throws up any other Exception, Twist treats it as an error. Scenario execution is stopped at that point.

More on Scenarios