One of the most interesting features of Agilitest is the ability to use sub-scripts. This will allow you to factorize common functions of your tests, such as the creation of test data, login, regularly used operations ...
An additional benefit is that you will be able to pass values as parameters to your sub-scripts, and thus make your sub-scripts scalable and generic.
Finally, if you properly manage the granularity of your scripts and sub-scripts, it will also allow you to have test scripts that are not too long, readable and easy to maintain.
Start by building a test with hardcoded values and no subscripts
The sub scripting action has been designed to make it scalable
Just start by modeling your test script : create actions, declare variables. At some point, you will realize that you have generated something that can be reused.
Then select the actions which interest you to create a sub-script, and drop them into a directory of the Project Explorer. Agilitest then asks you the name of your new script, creates it in the designated directory and generates the call of this sub-script in the original script. You have nothing else to do.
I want to be able to pass parameter
Your new subscript contains all the actions that interest you, but for the moment it will realize all the time these actions with the same parameters.
Obviously, what interests you is to be able to modify the values to use your sub-script in several possible configurations.
The most appropriate way to do this is to edit the subscript and modify the parameters of each action to "variabilize" them.
Variables that are passed to subscripts can be retrieved from them using the function: $param(value, default_value).
Thus, if you edit your script by replacing the hardcoded value with $param (value, default_value), you can both variabilize your sub-script but also use it with the values you declared when it was created, as you can see in the sample below :
The value you will use as the first parameter of the $ param() function is the index of the variable in the calling array of the subscript function.
Now that you have changed all the parameters in your sub-script, you need to modify the call parameters in the calling script.
Get back to your subscript call function
... by clicking on it, a popup will open and you can add a parameter
Finally, you will be able to add as many parameters as you want to your subscript call. For each of them, the index number of the parameter must correspond both in the calling function of the calling script and in the $param() function of the sub-script.
How to get the result
To retrieve the result of a subscript, you must first declare a variable in the Variables tab, menu, create a variable.
The created variable is purple, ie modifiable by the user.
Then you drop the variable into the subscript call function, and it appears as a return variable, orange and unmodifiable.
Subsequently, you must make sure that your subscript will return a return value.
In the editor, you can add this return value by clicking at the bottom left of your sub-script on the button "Add a return value"
You then retrieve the return values directly into your calling script.
If your script does not pass or does not return value, or does not use them, Agilitest and ATS wont stop the test.
These features will allow you to use your sub-scripts by entering the parameters hard, and in this case you can recover return values.
You can call your sub-script several times by entering the number of iterations you want
This is useful when you have a function that can be used several times in succession, for example a "back" function that returns to the previous window, which will allow you to check your UI's behaviours.
You can also ask Agilitest to iterate over the lines of a CSV file and invoke a subscript by passing the values of the columns as input variables. You do not get return values, but you call your sub-script as many times as you want.
The important thing to remember in this article: This feature will allow you, once your tests done in a simple way, to extract reusable sub-scripts, and then to give depth to your tests. testing your software with a wealth of data. Keep in mind that a software is bug-free until a client has found a runtime configuration that you have not tested, and this often involves using exotic data...