This is an old revision of the document!
Tutorial: Automation Scripting - State Model
Learning Objectives:
This tutorial assumes that you are able to create a simple State-based Model and have created a simple model to write scripts for. If not, please refer to Tutorial - State-based Modeling.
Model scripting
Apache Groovy script is the scripting language for your models.
Groovy script is syntactically very similar to most of programming language that allows you to create classes, functions and basic logic and arithmetic operations.
You will typically wrap your expected processing logic in a groovy function:
def MBT_Start () { $SYS.log ('inside MBT_Start TRIGGER'); }
The groovy function is then attached to the states and/or transitions in the model through annotation:
@TRIGGER('MBT_START') def MBT_Start () { $SYS.log ('mbt started. '); }
where 'MBT_START' is the identifier of system trigger (MBT_START) or UID of the state / transition, below is an example of transition trigger:
@TRIGGER('U1072') def 'Start: add25'() { $SYS.log('State Start, transition addQuarter'); }
You will need to add following “import” to the beginning of the script for the trigger annotation keyword:
import com.testoptimal.mscript.groovy.TRIGGER
Besides triggers, scripts are also used for building UI Page Objects, Cucumber style test step definition and MCases, which are out of scope of this tutorial. Please refer to Script Editor for more details.
Model triggers
Model triggers are model's execution hook to run groovy functions as model is executed. Model triggers include:
- MBT_START - executed at the beginning of model execution and before model automation starts
- MBT_END - executed at the end of model execution
- MBT_FAIL - executed up each defect (bug) detection
- MBT_ERROR - executed on fatal error during model execution
- ALL_STATES - executed when any state is traversed before specific state trigger is executed
- ALL_TRANS - executed when any transition is traversed before specific transition trigger is executed
- Specific state trigger - executed when the specific state is traversed
- Specific transition trigger - executed when the specific transition is traversed
Use the annotation @TRIGGER('id or uid') to attach a groovy function to the trigger.
To create a trigger function, press Ctrl-I in Script Editor and select the trigger type or a state / transition from the code assist list:
Below is an excerpt from a model trigger scripts:
// Model Triggers import com.testoptimal.mscript.groovy.TRIGGER @TRIGGER('MBT_START') def 'MBT_START' () { $SYS.addTestOutput('<html><body><H1>Test Output</H1>'); $SYS.addTestOutput('<ol>');\ $SYS.log ('mbt started. '); } @TRIGGER('MBT_END') def 'MBT_END' () { $SYS.addTestOutput('</ol></body></html>'); $SYS.saveTestOutput('testOutput.html'); } @TRIGGER('MBT_ERROR') def 'MBT_ERROR' () { $SYS.log('Fatal error encounter, path to reproduce error: ' + $SYS.trace()); } @TRIGGER('U1062') def 'State_1' () { $SYS.addTestOutput('<li><span>Test Case ' + $SYS.getPathName() + '</span><ul>'); $SYS.addTestOutput('<li><span>At state State_1</span></li>'); } @TRIGGER('U1072') def 'State_1: trans_A'() { $SYS.addTestOutput('<li>Step: trans_A</li>'); }
Feel free to add any additional scripts you wish.
Once scripts are completed, run the model and inspect the output file “testOutput.html” in ARTIFACT tab as well as Model Log file via menu Run / Model Log.
Activating plugins
Plugins provides additional script functions to interact with AUT or perform specific operations in the model scripts.
Plugins must be activated for each model as described in activating plugins. Follow the instruction to activate SELENIUM plugin for this tutorial. But feel free to experiment with other plugins.
After the plugins are activated for the model, the plugin IDs are automatically added to the code-assist popup list (Ctrl-Space):
Go ahead and activate Random Data Generator. This adds $RANDOM to the code-assist popup list. And now you can use any of the plugin functions provided by Random Data Generator.
For example:
$SYS.log('Random phone#: ' + $RANDOM.randPhone('999-999-9999') );
Web App Automation
For test automation, for example web application you would activate Selenium plugin. Once you have the plugin activated, you will be able to use $SELENIUM to interact with your web application through Selenium/WebDriver.
For example:
$SELENIUM.getWebDriver().findElement(org.openqa.selenium.By.id('DrinkWater').click();
Page Object
You could also use PAGES tab to define page object:
//PAGES Script import org.openqa.selenium.By; mainPage = $SYS.addPage('MainPage') elem = mainPage.addElement('DrinkWater', By.id('Water')) elem.addAction('click', { elem, params -> $SELENIUM.getWebDriver().findElement(elem.locator).click(); })
Then in TRIGGERS tab, you can do this:
$SYS.page('MainPage').element('DrinkWater').perform('click');
The advantage of using page objects is that all element locators are organized and managed in one central place for easy maintenance.
Find Element Locator
Web element locator can be xpath, css or by id, etc. as supported by Selenium.
There are many browser add-on/extension tools that can help you find locators for web element very easily. Check out External Sources for a list of such tools.
User variables
The variables that you created/declared in groovy scripts are local within the trigger/ function. Often times you may want to create a global variable that is accessible from multiple triggers / functions. User Variable does exactly that for you.
To create a user variable, call a system function:
$VAR.var1 = 100
And to reference a user variable any trigger functions:
$SYS.log ('User var1=' + $VAR.var1)
Typically you would declare all user variables that you want to use in MBT_START trigger so that you know what user variables are being used in the model and make sure they are initialized to a default value:
@TRIGGER ('MBT_START') def 'MBT_Start' () { ... $VAR.var1 = 100 ... }
Assert and track requirements
It's the responsibility of your scripts (TRIGGERS) to check and validate that AUT is behaving correctly. Your script does this by checking elements on AUT through plugins functions and assert that AUT elements have the expected values.
For simplicity sake, we will just use a random number generator to simulate the values from your AUT and use that to demonstrate how to perform the assertion and tracking the requirements.
The assert and tracking requirement are done with one of the two $SYS functions:
- $SYS.assertTrue ('tag', condition, 'fail msg', ['assertID'])
- $SYS.assertFalse ('tag', condition, 'fail msg', ['assertID'])
where 'tag' is the requirement tag/id, 'condition' is a boolean script expression and 'fail msg' is the failure description if the 'condition' is not evaluated to the true (for assertTrue()) / false (for assertFalse()). Optionally you may include 'assertID' which is the unique id assigned to this defect.
As example, the following script will assert random number is greater than 5:
$SYS.assertTrue ('GE5', $RANDOM.randNum(0,10) >= 5, 'failed to generate a random number with value at least 5');
You may also perform check with if/else and then raise the defect explicitly, for example:
if ($RANDOM.randNum(0,10) >= 5) { $SYS.addReqPassed ('GE5', 'Successfully generated a random number with value at least 5'); } else { $SYS.addReqFailed ('GE5', 'failed to generate a random number with value at least 5'); }
The requirement 'GE5' will be automatically tracked for the model and the coverage information is available in RESULT tab.
Add your own script to perform assertion and requirement tracking to the model TRIGGERS, re-run the model, and check RESULT tab.
Initialization scripts
Often times you may want to pass some configuration settings to your model scripts, for example, the AUT url which might change depending on if you are running your model against your development environment or QA environment or for this tutorial, maybe we want to change the threshold value of the random number the system must generate - which we have hard-coded to 5.
You could certainly accomplish this by setting Environment Variable via $SYS.getEnvVar(…). However a better option is to set a user variable for which the initial value can be set dynamically before the model execution starts. Initialization scripts accomplishes just that.
Initialization scripts can be entered in Model Execution Settings.