A step is an action block which is placed into (instantiated in) an activity diagram. When a step is triggered (usually by receiving its required data at its input pins), an activity is triggered, which performs the action of block. Note that multiple activities can execute the same step in parallel, if it is triggered multiple times AND has been configured to operate in parallel. Also notice, that multiple different steps can be (and often are) active at the same time. This happens when new data is arriving at a step's input, before the other activity has finished. If the parallelism is not limited, another activity will be triggered.
In workflow literature these terms are used in the same tenor. In UML literature the terms "action", "activity" and "step" are unfortunately used inconsistently. The expecco documentation strictly separates between "action block" (= action definition), "step" (= placed block) and "activity" (= executed step). Please note that an action block can be placed (instantiated) several times as a step and multiple activities could be actively executing the same step's action.
Types of Steps
Every step has an associated action definition, which is executed whenever the step is triggered. The internals of a step depend on how the action is defined. It may be an "elementary", "compound" or a builtin action. Elementary actions are defined by a piece of code written in a number of programming languages, compound actions are described by an activity diagram consisting of a network of interconnected steps. Finally, a small number of builtin actions is hard wired into expecco. Builtin actions are for example, "shell command action" steps and "attachment steps", for which no particular action definition or coding is required.
Regular steps have a number of optional data and control inputs and a number of optional outputs. Each input and output is presented as a pin in the action's schema definition and also shown in the step. The block's schema definition can be seen as a template, which defines the outside picture of an action when placed as a step into an activity diagram.
Attachment steps do not have data inputs, but only provide a single output pin, at which the attachment's contents is presented, when the step is triggered. Other than that, they behave like any other ordinary step. (in fact, an attachment could be easily simulated or reimplemented by an action which reads the file and passes the contents to its single output pin. So the attachment step is not adding any new feature, but can be seen as "syntactic sugar").
Triggering a Step
A step in an activity diagram gets triggered when its required input values are available at its input pins. The details for triggering are described in the pin documentation, and are controlled by the number and type of input pins. However, the vast majority of actions are declared with a simple and intuitive "All connected pins must have a value" as triggering condition (the so called "And-Connected Trigger Condition").
Actions with no input pins or where all input pins have constant "freeze values" usually have the "Autostart" attribute, which is described below.
Special Attributes of a Step
This attribute is used for steps which have no input pin, for triggering, and for which no other external trigger input is available. In traditional activity diagrams, this would be called the "Start" step, although in expecco, any step can be made a start step, and multiple such "autostarted" steps may be present within a single activity diagram. This simplifies the diagram, as no extra start step (which would provide no other semantic operation) is needed. However, for those who prefer the traditional picture, a dummy "Start" action is provided in the standard library, which can be used as start step.
In the diagram, autostarted steps are marked with a special "execute" icon at the top-left corner of the step's picture (in older expecco versions, and some screen shots in the documentation, this used to be a yellow lightning symbol, but has been replaced with a gear-wheel like icon, as it tended to be misread as an exception picture).
By default, an exception or error condition arising during a step's execution leads to the termination of the step's activity, and (unless handled) passed on to the caller activity. I.e. the step which is executing the faulty step's diagram is itself asked to handle the exception. This passing on of the exception continues until either the exception is handled via a step's exception pin or the step has been marked as "ignoring exceptions", or no outer calling activity is present (i.e. the test case which initiated the action is reached).
When a step ignores exceptions, it is terminated (and the optional exception output provides the exception information), but the diagram in which the faulting step is located is continued to be executed.
Cancel is OK
By default, a cancelled activity will trigger its exception-output pin, not its regular trigger-out pin. With the "Cancel is OK" flag set, a cancel is treated like a non-exceptional situation (i.e. it was expected to be cancelled) and the trigger output is written as usual (and no exception output is written)..
Individual steps in a diagram can be skipped by setting the "Skipped Execution" attribute. Such steps will not read any input data, not execute any action and not write any data outputs. However, the trigger output pin gets a value if present and connected. Therefore, steps in a control flow (i.e. only connected via Enable-Input/Enable-Output pins) can be skipped without a need to short-circuit their control pins. Of course, as skipped pins do not generate any data output, any step which requires those values would not be triggered.
Skipping steps is mostly used when debugging test activities or to skip over long running initial steps when an activity needs to be restarted after a change. They are usually not used after the test development process, in a production test suite.
These attribute suppress the activity log as normally generated either unconditionally or conditionally on a per-step basis during execution. For helper actions, which are of no interest, or steps which produce huge amounts of output, which is not actually required, setting this attribute both reduces the test's execution time and the amount of logging data that is generated.
For very long running tests (hours or days), it is recommended to use this attribute to ensure that the activity log fits the machine's memory size (to avoid running out of memory during the test run).
You can either unconditionally disable the activity log for a step or its subactivities or conditionally, based on its outcome, or if it part of a loop.
Augmenting the Step's Name in the Log
If a steps name contains the substring %i, where i is a number from 1 to the number of input pins, the step's name is expanded by including the input pin's value string in the activity log. I.e. if the input pin received a value of (say) 1234, then the step name "My Step (test data is %1)" will be shown as "My Step (test data is 123)".
In addition, the following expansions are possible:
- %(START) - expands to the step's execution start timestamp
- %(END) - expands to the step's execution end timestamp
- %(STATE) - expands to the step's outcome (fail, error, passed, inconclusive)