Rational Robot Tutorial: Setting Up Your Test Environment

<< The Recording Workflow | Enabling IDE Applications for Testing >>

Setting Up Your Test Environment

Before You Begin Recording

2-3

Establish predictable start and end states for your scripts.

Set up your test environment.

Create modular scripts.

These guidelines are described in more detail in the following sections.

Establishing Predictable Start and End States for Scripts

By starting and ending the recording at a common point, scripts can be played back
in any order, with no script being dependent on where another script ends. For
example, you can start and end each script at the Windows desktop or at the main
window of the application-under-test.

Setting Up Your Test Environment

Any windows that are open, active, or displayed when you begin recording should be
open, active, or displayed when you stop recording. This applies to all applications,
including Windows Explorer, e-mail, and so on.

Robot can record the sizes and positions of all open windows when you start
recording, based on the recording options settings. (For information about setting
the recording options, see Setting GUI Recording Options on page 2-5.) During
playback, Robot attempts to restore windows to their recorded states, and inserts a
warning in the log if it cannot find a recorded window.

In general, close any unnecessary applications before you start to record. For stress
testing, however, you may want to deliberately increase the load on the test
environment by having many applications open.

Creating Modular Scripts

Rather than defining a long sequence of actions in one GUI script, you should define
scripts that are short and modular. Keep your scripts focused on a specific area of
testing -- for example, on one dialog box or on a related set of recurring actions.

When you need more comprehensive testing, modular scripts can easily be called
from or copied into other scripts. They can also be grouped into shell scripts, which
are top-level, ordered groups of scripts.

The benefits of modular scripts are:

They can be called, copied, or combined into shell scripts.

They can be easily modified or re-recorded if the developers make intentional
changes to the application-under-test.

They are easier to debug.