Settings DebuggerSettings/en

Aus expecco Wiki (Version 2.x)
Wechseln zu: Navigation, Suche

Debugger Settings

Overview

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.

Allow Invalid Pin and Field Value Types

Controls if at execution time, generated output pin values are consistent with the pin's datatype. By default, this is not checked (i.e. allowed) and expecco "trusts" the code inside elementary blocks. This can be disabled during test development and enabled for test execution (it will slow down the execution a little bit)

Allow Empty Compound Activities (no Steps)

Controls if empty compound actions (i.e. unimplemented) are reported as an error.

Check for Empty Baskets when Compound Finished

If on, all input-pin baskets of the inner steps of a compound action's network are checked for being empty, when a compound action is finished. This ensures, that no missing trigger / missing data prevents other values from being processed.

Debug Pin and Field Value Types

Similar to the above "Allow Invalid Pin and Field Value Types" (which will lead to an Error exception), enable this to have a debugger opened when the situation arises.

Freeze Values are Immutable

(New in 18.1) Enable this (now the default) to make freeze value collections (especially strings and arrays) immutable. If passed to tother steps, which try to modify the contents, an error will be reported. Typically this happens, when a frozen String or Array is passed to an "ElementAt:Put" block, or the string is modified inside a user written elementary block. If your old test suite does actually depend on a mutable freeze value (which is unlikely, bad style and should be punished), disable this feature in the settings.

Enable 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 "halt()" in JavaScript, or "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.

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: RunWithDebugger.png

Debug Activity Code

Controls if a debugger is opened for errors/exceptions which happen while an activities' elementary code is being executed. This only applies to user-coded elementary actions (i.e. those with Smalltalk or JavaScript code). No debugger is opened for errors in remote procedure calls. Also, no debugger is opened if the exception is handled or ignored by the current activity.

Debug Handled Exceptions in Activity Code

Controls if a debugger is opened for errors/exceptions which happen while an activities' elementary code is being executed. This only applies to user-coded actions (i.e. those with Smalltalk or JavaScript code). No debugger is opened for errors in remote procedure calls.

Debug Expecco

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 new 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.



Copyright © 2014-2018 eXept Software AG