Editor: Managing Scripts

The script management panel organizes and provides quick access to the scripts and sections necessary for creating complex behaviors. The script management panel is divided into three parts:

The script management panel.
  • Top-level scripts that serve as the main entry points for execution with Alyvix Robot (MAIN, FAIL, and EXIT)

  • Sections, which are user-defined subroutines that can be used inside other scripts

  • Maps , which are user-defined tables of keys and values that can be used to (a) take a text string scraped from the screen and map it to another string, or (b) loop over a test case object (using the FOR expression) for as many rows as there are in the map’s table

From the script management panel you can:

  • Click on the name of a script or map to show its contents in the scripting panel

  • Add a new Section or Map element (see below) with the ADD action

  • Delete an existing section or map element with the REMOVE action

  • Use the icon to drag a section or map element and drop it at any desired point in the currently opened script in the scripting panel

  • Use the lineadd-icon action to add a Section (as a RUN expression) or a Map (as a FOR expression) to the bottom of the currently opened script in the scripting panel

  • Use the action to immediately run a Section script against the current interface as though you had pressed the runblue button

Top level Scripts

The following scripts are predefined and are executed by Alyvix Robot at the appropriate time:

  1. Main: The principal script that is invoked when launching a test case from either Alyvix Editor (via the runblue button) or Robot

  2. Fail: A script that is executed if one of the test case objects in the Main script having the Break flag not set times out

  3. Exit: A separate script that is always run once the Main script terminates, allowing you to restore your application and environment to its prior state (for instance, to shut down a browser that was launched as part of a test case)

Sections

Sections are subscripts (subroutines) that can be called one or more times by name from other scripts or subscripts. This can greatly help improve the readability of scripts, especially when they become very long.

When you insert or replace a test case object with a section in the scripting panel, the color will become dark green to indicate it is a section. A link icon will appear, and clicking on it will load that section in the scripting panel.

Note

You cannot use a section as the antecedent (condition) in an IF TRUE or IF FALSE expression, although you can use it as the consequent, or as the argument of a FOR expression.

Tip

You may find it useful to explicitly mark sections and maps using their names, to avoid potentially confusing them with test case object names, e.g.: logout_section or download_map.

The Map Interface

The Maps feature lets you create a table of strings that you can use to (a) map a string scraped from an application (the key) to extract another string (the value), or (b) loop over a test case object or a section, once for each row (top to bottom) in the map.

Note

Rows are automatically sorted alphabetically by the key, so if order is important, it should be reflected in how the keys are named.

You can add a new map by clicking on the ADD button next to MAPS in the script management panel. You should then change the name of the map from the default to something that helps you easily remember what it’s used for.

The first step after creating a map is to define the set of keys and values that can be inserted. The map interface is shown here, with the available actions listed below:

The Map interface.
  • ADD ROW — Add a new row to the bottom of the table

  • ADD COLUMN — Add a new column to the right of the table

  •   — Delete a row or the rightmost column

When a test case containing a map is executed, measurements are collected for each iteration of the map. These measurements are output when execution in CLI mode has completed.

Debugging Scripts

When composing scripts, you often need to check that one or more of the test case objects you’ve just created work correctly before proceeding to build the following one. As your scripts get longer or more complex, regularly testing objects becomes more important. Without it you risk losing significant time when you have to modify later objects in the script because an intermediate one was built incorrectly.

There are two main problems to overcome when debugging scripts:

  • Executing a script either via the runblue button in Editor or via Alyvix Robot will launch the script from the very first node, although what you often need during debugging is to start at an intermediate stage

  • When starting at an intermediate stage, the application or browser’s interface must match the expectations of the (first) test case object being debugged

There are several methods you can use to debug both individual nodes and parts of scripts, as opposed to the entire script:

  • Use the Disable/Enable functionality to temporarily turn off nodes in the scripting panel that don’t need to be tested, and then press the runblue button. Note that when done, you must remember to re-enable the scripting nodes.

  • Use the action in Selector to either run a single test case object or to run a single section. (Note that running a section this way will run every enabled scripting node in that section.)

  • Select one or more scripting nodes with the mouse and then use the Run Selection button to run just those nodes. Unlike disabling, you do not need to remember to re-enable them later.

When using both the disable/enable and run selection strategies, you can select the starting point of the script to match the current state of the application or browser’s interface.