Debugging Tests - Overview

Applies to TestComplete 15.64, last modified on May 16, 2024


TestComplete includes two debuggers: the keyword test debugger and the script debugger as an aid in developing your keyword tests and scripts. Debugging refers to halting the test execution on a certain keyword test operation or script line and then running through the test in step with the execution, stopping on operations or script lines. Every time the debugger stops somewhere, there are several things it will allow you to do, such as to check or change the values of variables. However, merely stopping before certain operations or lines is often a great help in tracking what your test is doing.


The keyword-test and script debugging functionality is built into TestComplete and does not have any special requirements.

Enabling the Debugger Functionality

The debugging features work when the  Enable Debugging item is checked. If the item is unchecked the debugger is off.

Also, the debugger is off if TestComplete is opened in Silent mode.

Using the Debuggers

Running Test Under Debugger

The script and keyword test debuggers are very similar to each other. They have the same methodology of use and share the same panels, dialogs and menu items. The debugger actions are available from the Debug toolbar or shortcuts. The toolbar contains the execution choices of the debugger. Each of these is the equivalent of a Run button, but with two differences:

  • First, on a new run, execution starts at the top of the first executed routine or keyword test. But after each stop it will resume at the line or operation, at which the debugger stopped.

  • Second, each execution choice is a different way of selecting the next line or operation, on which the debugger will stop. The two main ways to debug a script are --

    • The debugger can stop before every executable line in the script or on any operation of a keyword test. There are two variations, tracing or stepping over. See Stepping Through Test.

    • The debugger can run through the test from the current execution point, without stopping, to the line or operation that the cursor is on. Execution will stop just on that line or operation (before executing the line or operation). This is one way of going straight at suspect code. See Running to the Cursor for more information. Note that execution will not stop until the end of the test run if the cursor line or operation is simply never executed.


Script lines and keyword-test operations can also be preset for the run to stop when reaching them. These lines are called breakpoints. A breakpoint is a location set in your script or keyword test where you want the test to pause during execution. Once the execution is paused, you can check the state of the test, its output and its variables.

Setting a plain breakpoint is the same as running to the cursor, except that you do not have to set the cursor at the script line or operation (it is memorized) and you can have several breakpoints. You can also have conditional breakpoints, where the debugger stops only if, at that point in the run, a certain condition you defined is true. Breakpoints work no matter how execution is controlled - even from the Run button on the Script toolbar. See Using Breakpoints for more details.

Note: The script debugger executes statements in line increments. It cannot stop in the middle of a line that has multiple statements; it will always execute them all together. If one statement spans several lines, it will execute the entire statement in one block.
Activating Debugger During Test Run

You can also pause the execution from the script or keyword test by calling the Runner.Pause method. Also, if the Pause test execution on posting an error option is enabled, TestComplete automatically activates the debugger when an error message is posted to the test log. See Activating Debugger From Tests for complete information.

Evaluating Data During Debugging

After you pause the test execution using a breakpoint or any other method, you can check the value of script variables and expressions. You can do this in any of the following ways:

  • If you debug a script unit, place the mouse cursor over a relevant variable name or expression in the Code Editor.

  • Use the Evaluate dialog that lets you find the value of any expression you can define with available variables and usual arithmetic and logical operators.

  • Use the Locals panel to explore the values of all the variables defined in the current script routine or keyword test. The panel also display the values of the routine’s or test’s parameters.

  • Use the Watch List panel to set up a list of the expressions to be evaluated every time the execution stops.

Viewing Call Stack

You can also see the sequence of script calls and keyword tests that led to the current line being executed using the Call Stack panel. The list is displayed in the order in which the routines and tests were executed, with the most recent-called routine (recent-executed test) at the top.

Changing the Execution Flow

During the pause, you can change the execution flow by specifying the next line or keyword test operation for execution. Using this feature you can skip or re-execute the desired test parts. See the Setting Next Execution Point help topic for detailed information.

See Also

Debugging Tests

Highlight search results