TPT User's Guide - PikeTec

Page 74 TPT User’s Guide
This method is called capture & replay and, besides providing independence of the target
environment, provides an additional advantage: a test run may be “debugged” repeatedly on
the basis of a single test execution. This can save a lot of time.
As in conventional programming languages it is possible to use a breakpoint in TPT to
interrupt a test driver in its execution after reaching an internal state of the automaton specified
by the user. Breakpoints may be added or deleted during the runtime of a debug session.
As soon as the breakpoint has been reached all currently active states of the automaton are
displayed. This also applies to all automatons that are used within the currently debugged test
scenario. Thus, following conventional programming environments, all elements starting from
an active state and describing a path through the automaton hierarchy up to its root can be
understood as a stack-trace.
To continue stepping through the interrupted test execution the user may
• Resume the execution for one discrete step in time (step cycle).
• Resume the execution until the next state transition (step over).
• Unconditionally resume the test execution (resume).
The execution of a TPT automaton may be stopped by the user at any time.
14.2 Debug plug-in features
The debug plug-in complements the application by supplying additional functionality needed
for debugging. These extensions can roughly be divided into two sections: extensions to the
user interface for modelling automatons or test cases and extensions to the test execution
process to facilitate debugging of the execution.
14.2.1 Extensions to the user interface: definition of breakpoints
The set-up and the semantics of breakpoints are defined as follows:
• A breakpoint must be defined within the context of an automaton. This may be the
root testlet.
• A breakpoint must be defined within the context of a scenario or a scenario group. If
no scenario has been selected the default group of “all scenarios” will be used.
• A breakpoint which is defined at the scenario group level applies to all scenarios and
scenario groups contained therein. This mechanism is called inheritance or
propagation of the breakpoint.
• A trigger is the event which activates a breakpoint. There are trigger variants “on
entry” and “on event”. The trigger variant “on entry” lets the breakpoint become active
every time the execution of the test reaches the set state. In the trigger variant “on
event” a condition also has to be logical “true”. The condition has to be stated in the
“event” column and follow the syntax of TPT.