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