Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

MAJ 03-01-24

The Greenspector Domain-specific language (GDSL) is used by Greenspector Studio to describe an user journey. By convention, files written in GDSL use .testgb extension.

Basic structure

To indicate what needs to be measured, the same structure is used for each step: 

measureStart,STEPNAME
instructions
measureStop

Every instruction between measureStart and measureStop will be measured while everything outside will be ignored:

measureStart,STEPNAME1
# Measured in STEPNAME1
instructions
measureStop

# Not measured
instructions

measureStart,STEPNAME2
# Measured in STEPNAME2
instructions
measureStop

Format

Some rules has to be respected for a fully working automation:

  • 1 instruction by line

  • comment with # on a separate line

  • eventual parameters follow instruction separated by ,

A parameter which contain symbol , isn’t allowed.

Example In GDSL: 

# comment
measureStart,STEPNAME
enterText,my first text
measureStop

Instruction

Several instruction are available to automatise an user journey. Here are the prefix of the main commands:

  • application instructions are related to start, kill, clear, install or uninstall apps

  • assert instructions allow to check the presence of an element

  • browser instructions are special instructions to manage browser for web tests

  • click instructions offer several way to click on buttons by text, id, position, etc

  • find instructions browses in UI elements hierarchy to easily find to a specific element

  • pause to pause test during a certain amount of time

  • press instructions are useful to activate special buttons, as keyboard or physical buttons

  • scroll and swipe instructions allows to move on a page horizontally or vertically. scroll reproduces a movement where finger press screen, then move, then release. swipe reproduces only a sliding movement.

  • wait instructions are helpful after a page change to wait a page to be fully loaded

Others specific commands exists to manipulate texts, settings, screen, form, OTP authentifications, etc.

The global documentation can be found here:

Measure type

Four type of measures are used, and currently indicated in prefix of step name:

  • CHRGT_ for loading steps:

    • Typical use is display of a new view : application start, button click resulting a page change

    • It has to finish with a wait instruction to wait for full loading

assertNotExistsText,Accept cookies
measureStart,CHRGT_example
pressEnter
waitUntilText,Accept cookies
pause,${PAUSEAFTERLOAD}
measureStop

  • PAUSE_ for pause steps:

    • Typical use is to observe the behaviour of the page without user action to detect unusual data or energy consumption

measureStart,PAUSE_example
pause,${PAUSEDURATION}
measureStop

  • ACTION_ for action steps:

    • Typical use is an action with doesn’t result in the display of a new view

    • Multiple action can be grouped if it makes a functional sense

measureStart,ACTION_example
clickByText,Accept cookies
pause,${PAUSEAFTERACTION}
clickById,onetrust-accept-btn-handler
pause,${PAUSEAFTERLOAD}
measureStop

  • SCROLL_ for scroll steps:

measureStart,SCROLL_example
swipeDown
pause,${PAUSEAFTERSCROLL}
swipeDown
pause,${PAUSEAFTERLOAD}
measureStop

We notice a pause before the end of each step to measure residual consumptions and loads.

A common practice is to use a variable to define the pause instruction at the end of each type of step.

Variables use in GDSL will be explained in the dedicated section.

extras:
  PAUSEAFTERLOAD: 1000
  PAUSEDURATION: 30000
  PAUSEAFTERACTION: 500
  PAUSEAFTERSCROLL: 500
  • No labels