When you record a GUI script, Robot records:
- Your actions as you use the application-under-test. These user actions include keystrokes and mouse clicks that help you navigate through the application.
- Verification points that you insert to capture and save information about specific objects. A verification point is a point in a script that you create to confirm the state of an object across builds. During recording, the verification point captures object information and stores it as the baseline. During playback, the verification point recaptures the object information and compares it to the baseline.
The recorded GUI script establishes the baseline of expected behavior for the application-under-test. When new builds of the application become available, you can play back the script to test the builds against the established baseline in a fraction of the time that it would take to perform the testing manually.
The Recording Workflow
Typically, when you record a GUI script, your goal is to:
- Record actions that an actual user might perform (for example, clicking a menu command or selecting a check box).
- Create verification points to confirm the state of objects across builds of the application-under-test (for example, the properties of an object or the text in an entry field).
Before You Begin Recording
You should plan to use Robot at the earliest stages of the application development and testing process. If any Windows GUI objects such as menus and dialog boxes exist within the initial builds of your application, you can use Robot to record the corresponding verification points.
Consider the following guidelines before you begin recording:
- Establish predictable start and end states for your scripts.
- Set up your test environment.
- Create modular scripts.
- Create Shared Projects with UNC.
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. 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 rerecorded if the developers make intentional changes to the application-under-test.
- They are easier to debug.
Creating Modular Scripts with UNC
When projects containing GUI or Manual scripts are to be shared, create the project in a shared directory using the Uniform Naming Convention (UNC). UNC paths are required for GUI test scripts and Manual test scripts that are run on Agent computers.
