Settings DebuggerSettings: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Cg (Diskussion | Beiträge) |
Sv (Diskussion | Beiträge) (Weiterleitung nach Settings DebuggerSettings/en erstellt) |
||
| (3 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
#redirect [[ Settings DebuggerSettings/en ]] |
|||
| ⚫ | |||
[[Category: Empty]] |
|||
=== 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 alot 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: [[Datei:Beispiel.jpg]] |
|||
=== 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 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 "<CODE>halt()</CODE>" call into your code, explicit (programmed) breakpoints can be added |
|||
to your elementary code. Typically, this is a statement like "<CODE>this.halt()</CODE>" or simply "<CODE>halt()</CODE>" |
|||
in JavaScript, or "<CODE>self halt</CODE>" 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. |
|||
=== 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 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. |
|||
| ⚫ | |||
Aktuelle Version vom 8. Dezember 2015, 17:17 Uhr
Weiterleitung nach:
