Creating Test Actions
Introduction
To explain how to create a Vitaq AI Test Activity we are going to test a simple shopping web App https://www.saucedemo.com
The shopping web App has three main user screens for login, selecting products and checking out purchases. We abstract the tests we want to perform on these screens into Vitaq Test Actions. On each of these screens there are user actions that perform a sort, continue and logout so we will also need Test Actions for these.
Each Vitaq Test Action maps to a webdriverIO spec file. The name of the Vitaq Test Action and the webdriverIO spec file needs to be identical (except for the file name extension), e.g. products <--> products.js where product is the Vitaq Test Action name and product.js is the WebdriverIO spec action file for Vitaq. The test code for each action is written in JavaScript mocha BDD/TDD pattern and will use the same WebdriverIO syntax as you would usually use. The logical flow of the code needs to take into account that each WebdriverIO spec action file needs to execute from Action to next allowable Action. So the WebdriverIO spec action file's JavaScript code in each Action needs to be written in such a way to handle the dependency of a "User Journey" where one Action is executed followed by the next allowable "connected" Action in a Test Activity diagram. Whereas stand-alone WebdriverIO Spec files are typically written as independent tests which can be run in parallel. Vitaq spec action files follow the end-to-end user journey from the starting Action through allowable Actions to a completing Action.
The first test action we will define is one called login.
When you have logged into vitaq.online and open the Test Activity diagram in the user interface you can add a Vitaq Test Action by clicking on the Add New Action button in the top left corner of the canvas. You will notice it will now have a highlighted background with a glow around it to denote it is selected and your cursor will change to a cross. Having this mechanism allows multiple actions to be created one after another whilst in the test action creation mode.
Click inside the test activity canvas to create a new test action at the point that you click. Fill in the New Test Action name field and select the colour you want. We have used dark green. Being able to select the colour for a test action, enables users to differentiate test actions or groups of actions from others. The default colour for a test actions is dark green, once a colour for a test action is selected this will remain selected until a different colour is chosen. To change the name of a Test Action, select the Action Properties tab and then select the test action you wish to edit.
You can move the starting Action (the green circle) to the top left of the canvas and the login Action to be down and slightly right of it as shown below. Click and hold on the Action and then drag to the position you require. You will notice that it will snap to a grid. The grid settings can be changed in your Test Activity settings in the Dashboard.
Do the same for products and sortItems
Deselect the Add New Action placement banner menu button by clicking on it. It will no longer be highlighted.
Now you can pan across the background of the canvas by clicking and holding empty space in the canvas and dragging it. So you can move the start action back up to the top left corner.
Click on Add New Action again, to start creating the new Action for backpack, onesie, bikelight, tshirt_red, tshirt_bolt, fleece, shoppingCart and continueShopping as shown below.
Navigating Around the Activity Diagram Window
In this guide we are creating a simple Test Activity which will easily fit in a relatively small Activity Diagram Window. Users will create significantly larger Activity Diagrams, to help navigate round these we provide four tool bar options: Zoom In, Zoom Out, Zoom 100% and Fit as well as the ability to click and hold on the canvas and drag the whole canvas into a view you prefer. If your mouse has a scroll wheel this will also zoom in and out.
Disabling Test Actions
There may be certain Test Actions which you currently do not want to ‘enter’ in your Test Activity. Maybe because they stop the test flow prematurely or they are not important at this stage in your Test Activity development. This can be handled in Vitaq by disabling this Test Action.
To demonstrate this, we will disable sortItems. By default, all Test Actions are enabled when instantiated into a Test Activity. We disable it in the Action Properties tab. Click on the sortItems Test Action in the Test Activity window and then click on Action Properties. Click on the Enabled check box to remove the tick.
You will notice the No Entry sign in the top left of the Test Actions that are disabled. This means that the Test Activity cannot enter these Test Actions when running a test. To start building out the Test Activity it is good practice to work on a few Test Actions at a time by disabling the ones you do not yet need.
Global Actions
To reduce the amount of Test Activity connections needed when you have many actions 'inter-connected' we have created a special type of Test Action called a Global. These are especially useful when in every app screen you have a button, such as "logout", a menu driven "back" and "checkout" as needed in our simple web shopping app.
You can change an existing action or define a new action to be global by editing the Action Properties for that Action and clicking the Global tick box as shown below with the yellow highlight.
Here we have created a New Action called back, defined it is as Global and set its probability to 30%. Vitaq now has a 30% probability of selecting this Global Action as an allowable Test Action from any of the test actions in the test activity. If we want to exclude this global action from being selected as a next "allowable" action then we can define which actions are to be excluded as we have done for the back button, which is not available from login, logout etc.
There are three different types of Global action. The default as shown above is Return. Which defines a global action that will return to the test action that it came from. Perfect for a "Check Cart" button in a shopping app or screen rotations in a mobile app, so that you rotate the screen and then return to the end of the test action script that it came from and continue with the user journey. Note that the return to global action should only be used in cases where the global action does not affect the state of the app in a way that would mean that following actions would not be able to execute e.g. by causing the app to return to the log in page.
End type Global Actions are perfect for quit or logout type operations where you want many actions in the test activity to be able to logout from the app. Here the shopping app can logout from any screen but we don't want it to cut short all of our user journeys being created so we set the probability to just 10%.
The third type of global action is a Connected action. This is useful where you want a global action to be the next allowable action from any of the Test Activity actions, but you want the global connected action to only have certain actions as allowable next actions. For example where you have a shopping basket icon on all screens, but once selected it will take you to the checkout_basket test action. Global 'connected' type actions can only have arrows drawn from them to other actions. You cannot draw arrows to a 'connected' type global action.
Whenever you have arrow connections to a global action, say from previous test activity 'normal' actions that are changed to globals, you will notice that the arrows are then greyed out. Which means they are disabled from the test activity. They can be re-instated if you change the test action to a non-global.
Setting Call Limits on test actions
To control how many times a Test Action is called in a Test Activity run, we can use the Call Limit property on the Test Action. For example, say we want our Test Activity to only call the global action "back" once in a Test Activity run. To do this we need to set Call Limit properties on the back Test Action to be 1. Start by selecting the back Test Action by clicking on it. You will notice the back Test Action highlights (see below), click on the Action Properties tab to see what default properties back has. To change the Call Limit property, click in its edit field and change the default value (0) to 1. It is important to understand that this is a Call Limit not a target, so once the limit is met that action will no longer be called by the Test Activity. Whenever you highlight a Test Action its properties will be displayed in the Action Properties tab. If you do not want to have a call limit set on the Test Action, so that the Vitaq Test Activity will continue to call it as a next allowable action during a run, then set the call limit to 0. The test action will then not display any call limit in the test activity.
When you set the call Limit on the Test Action property, you will see the new Call Limit displayed on the Test Action in the Test Activity pane. If you set it to 0, then a limit is not displayed.
Continue on Error
If there is an error in the code that interacts with the Vitaq Library Methods, for example the script attempts to clear the call count on a Test Action that does not exist e.g.
await vitaq.clearCallCount("nonExistentTestAction");
then the default behaviour of Vitaq is that the test run will stop and the details will be output to the WebdriverIO console as errors. This is a logical default as it means that something has gone wrong and most likely the rest of the test will not proceed as expected thereby creating more errors which may mask the initial cause.
If you want to change the default behaviour of Vitaq AI to continue onto the next allowable Test Action selections, then you need to use the Action Property ‘Continue on Error’ for the specific test Action in question (as shown below).
This should not be confused with errors that occur in code in the test script that does not interact with Vitaq, for example a failed assertion, an error in the JavaScript code or an explicit “throw” statement. In these cases, the test will continue to run and can be controlled with the WebdriverIO 'bail' option.
