## Using Testing Macros

Test scripts can be modularized using macros which define actions which are repeated (e.g. opening dialogs, starting the application, typing into a text field etc.) This makes the scripts easier to create, amend and check by hand.

### Example of Scripts Using Macros

In order to illustrate how macros can be used to create modular scripts, an extract from the visu test scripts is listed below as an example. This short script does the following:

1. Starts visu

2. Creates a design containing a Shell and Form

3. Gives the Form a variable name

4. Saves the design, specifying a filename

5. Exits visu

To do this in a way which makes the top-level script more readable, we shall use the macro preprocessor, m4. This is available on all UNIX systems.

The high-level script to do the above is:

        include(Defs.m4)
        StartUp()
        shell   date
        Palette(xd_XmDialogShell)
        Palette(xd_XmForm)
        VariableName(myform)
        SaveDesignAs(mydesign.xd)
        message Test Sequence Over
        shell   date
        Finish()

Most of the above script consists of macro calls.

The macro definition script, named Defs.m4, looks like this:

    define(HandleExpectedWarning,
    	in warning_popup
    		push warning.OK)

    define(StartUp,
    	if !IsPseudoColor
    		message Non PseudoColor display
    		HandleExpectedWarning()
    	endif)

    define(Palette,
    	in ApplicationShell
    		push $1)

    define(VariableName,
    	in ApplicationShell
    		multiclick nb_vn_t
    		type $1
    		key Return)

    define(SaveDesignAs,
    	in ApplicationShell
    		cascade file_menu
    			select fm_menu.fm_saveas
    		in save_dialog_popup
    			doubleclick Text
    		type $1
          push save_dialog.OK)

    define(Finish,
    	in ApplicationShell
    		cascade file_menu
    				select fm_menu.fm_exit
    		if in save_changes_dialog
    			push xd_question.xd_question_cancel_b
    		endif)

The following command:

    m4 Test.in > Test.xds

creates the final script file which can be passed to WorkShop Visual Replay. The file Test.in is the high-level script and Test.xds is the output file which will contain the final script with expanded macros.

Try out this example by typing in the files listed above and then using m4 to make the final script file. Having done this, run WorkShop Visual Replay with visu specifying Test.xds as the script to be replayed:

    visu_replay -f Test.xds visu

You could take this example one step further by defining the palette widget names in a separate file and then defining the "Palette" macro so that it looks up the widget name from a high-level name such as "shell" or "form":

    define(shell, xd_XmDialogShell)
    define(form, xd_XmForm)

In this way the internal names are kept in one place where they can be maintained and changed more easily.

See also:

- Testing with WorkShop Visual Replay
- Getting the Most from WorkShop Visual Replay