Print

Test steps

Test steps are the actions that JOSF executes against your Application Under Test (AUT). A test step can either be a direct action, a Page Action or an API Call.

Direct action

A direct action requires an action name (what to execute), an object (where to execute) and data. Note that the object or data might be required, but make sure you read documentation of actions.

Action name

Web actions

An action is executed against your AUT. This could be your application through a web browser (Web actions) or against a service (API actions). Web actions are always executed against a web browser. The most common, and important web actions in JOSF are;

  • type
  • click
  • select
  • open
  • verifyText / verifyTextContains
  • waitForObjectPresent/ waitForObjectNotPresent

Next to that, there are a few important Core actions;

API actions

API actions are always executed against the last API response. API actions are used to validate certain (parts of) API responses, but requires a previous executed API Call .

Object

The object field determines against what object the action is executed against. An object could be a text field, a button, some text, a heading, etc. when you execute a web action. When executing an API action, the object field could be used to find objects with XPath (for xml API responses) or JsonPath (for JSON API responses).

Note that objects in an API response are called nodes.

Objects in a web browser are found through multiple strategies:

  • className
  • cssSelector
  • id
  • innerText
  • linkText
  • name
  • partialID
  • partialLinkText
  • tagName
  • value
  • XPath

To help you find objects and use the most appropriate strategy for your objects in a web browser, make use of the Page Scanner.

Page Scanner

The page scanner helps finding objects in your application, by scanning the page based on a set of filters. After performing a scan, you’ll be presented with a list of found objects from where you can view of select the given object. Each object has a set of usable location strategies and a uniqueness level. The lower this level, the better JOSF will find that object in the future.

Note that it could happen that a strategy is found, but not selectable. This happens with the innerText. In that case, it’s currently not possible to select this strategy.

Page actions

Page actions are used to combine frequently used test steps which can be parameterized. If you have any input variables set in your page action, JOSF presents a way to enter your data.

Note that JOSF not only passes the input variables into the page action, but will also set the variable value in the test context. This way, you’d be able to use the set variable in any following test steps.

API Calls

Once API’s are imported or modelled in JOSF, you can use API requests during your tests in a test step. First select the given host, then the resource you’d like to use, and then the actual request. This will execute the modelled request.

Note that the execution of an API Call will always be successful. Testing the response of the API request, e.g. the response time, the response status code, or the body, will be executed through API actions.

Good practice: Wrap API calls in a Page action

If you are using any variables in your API calls, the variables used in that request are not shown when using them as a test step. To set those variables easily, you can wrap your API calls in page actions, and add input variables per variable used in the request. By then using the Page action in your test step, JOSF will present you with the required variables.

Data sheet

To enter variables in a bulk way, you can use the data sheet step. The data sheet step requires a data driven storage object with the data sheet type set to Variable sheet.

Then, from your test cases or step definitions, add a new data sheet and from there select the data sheet you’d like to use.

Data sheet types

There are 3 data sheet types, that defines what data is selected during the test execution. In the example picture above, there are four rows of addresses, and during the test execution, only one row will be used. To decide what row is used, there are three options;

  1. Row by name
  2. Random row selection
  3. Filter by value

Once this test step is executed, the variables are filled with their corresponding data and usable in all test steps beyond this point.

Upon step execution, JOSF will present the option to view the used variables, which is stored in the reports as well. To view the used variables, select the Toggle used variables option from the step menu, after the execution.

Row by name

The row by name lets you choose what exact row is used during test execution. In the example below, the Amsterdam residence is picked from the list of possibilities. This list is populated by the names that you’ve entered in the first column.

Random row selection

With the random row selection, JOSF picks a row during test execution randomly.

Filter by value

The filter by value option has currently only one filter type, which is the filter by variable value. This allows you to create a subset of the data sheet, based on the given variable name. You can select one of many comparators to create the subset. If more than one row results from the filter, JOSF will perform a random row selection on the subset to pick one during test execution.

Single row results

In the following example, the ${city} variable must be equal to “Amsterdam”. This will result in a single row which is selected during test execution

multiple row results

In the following example, the ${house number} variable must be less than 50, which should result in either the Berlin residence or the Madrid residence row. JOSF will randomly pick one of the two during test execution.

Note how JOSF will present the possible values based on the given filters. You can scroll through the filtered results and can use this view to easily copy-paste the variables into future steps.

You can open this view by opening the step menu and toggle the Toggle variable view option.

In this document