- 1 Debugger Settings
These settings control if a debugger is to be shown when errors, exceptions and breakpoints are encountered. For free running tests (and also, if expecco is executed under the control of another QM master), these flags should be off. In that case, breakpoints are ignored and errors/exceptions lead to the corresponding activity/testcase to fail.
However, during test development, the debugger is a very useful tool which helps a lot in finding errors inside the testsuite itself. You will probably want to enable the debugger then.
Notice, that the individual block test/demo execution offers two run buttons, one using the settings as set in the expecco settings (i.e. the same that will be active when the suite is executed as a whole), and another (with a little bug in its icon), which enables debugging, no matter what was specified in the settings.
During test development, you will usually want to use that debug-run.
Debug all Exceptions
Controls if a debugger should be opened for all exceptions; this includes internal notifications, such as inconclusive, success and failure notifications. Also, this affects the behavior for non-coded elementary actions. With this flag on, executions behave the same as if started with the "Debug-Run"-button:
Debug Activity Code
Debug Handled Exceptions in Activity Code
Debug Pin Value Type
Controls if a debugger is opened if the output value for a pin is not compatible with the pin's datatype. This is checked during execution.
Debug 'halt' Messages
By placing a "
halt()" call into your code, explicit (programmed) breakpoints can be added
to your elementary code. Typically, this is a statement like "
this.halt()" or simply "
self halt" in Smalltalk code.
This flag controls if a debugger is opened when such a program breakpoint is reached.
For debugging, these halts can be put into elementary code, where a debugger is opened
for single stepping or to look at the activities' local variables. For real test execution,
halts should be disabled.
The default is to ignore halts.
Allow Empty Compound Activities (no Steps)
Controls if empty compound actions (i.e. unimplemented) are reported as an error.
Controls if a debugger is opened for errors/exceptions which happen inside expecco itself (i.e. not related to user-written activity code or test execution). In the best of all worlds, there are no such events, but well... This should normally only be turned on by the expecco development team.
Suspend Actions while a Debugger is Open
If checked (which is the default), new activities are blocked from being executed in parallel, whenever a debugger is already open. This prevents the popping of many debuggers, if there is an error (or an explicit halt) in a step's activity, which is triggered multiple times. Especially, if it is triggered by incoming streamed values.
You should only uncheck this, if you are about to debug producer/consumer scenarios, in which you want to single step through multiple activities in parallel.
MessageTally on Execution
If checked, execution times of elementary activities are measured and an execution profile is generated after the execution (on the Transcript window). This is useful to find out where time is spent for performance optimizations.