Element tests are defined as a series of steps, which are run in sequence. Unlike other functional testing tools which encourage step isolation, Element is about defining a user journey through an application as a series of steps.
During execution, the timing of each step can be measured so that you can profile the throughput and performance of specific sections of the user journey. Timing can be measured as wall clock time, network time, and subsets of each.
You first need to import the step creator from the Element package:
Each test must export a default suite, which is what Element will use to detect the steps to run:
The next step is to define a list of steps using the step helper:
Here we've defined 3 steps, giving each a descriptive title and a callback function which will contain the actual business logic of our test in the form of test actions.
#Defining test actions
A test without actions is pretty bare, so let's instruct the browser to navigate to a page:
You'll notice that we pulled the
browser from the first argument received by the callback function. You also have access to the current
row of test data if you've specified a test data service.
The browser exposes every action avaialable to you at a top level for interacting with the page. See the Browser API page for a complete list.
A test step can fail for a number of reasons, most commonly because the state of the page was not as expected. These unexpected states may result from your application being overloaded and not displaying the expected page elements, an error message being shown, or test data issues. For example, your script may be attempting to add an out of stock item to a cart.
Handling failures is part of building a robust load test suite. Element provides a number of methods for this:
Recovery steps define an optional step which is called if a previous step fails, and can then perform a series of actions to return the application to a known state.
There are two types of recovery steps: global and local.
Global recovery A global recovery step is executed in response to failures from any step in the script. This type of recovery step can be useful for application-wide error messages or alerts. Global recovery steps are executed only for steps without a local recovery step.
Local recovery A local recovery step is executed in response to a failure in a particular step only, and it does not apply to failures in other steps. A local recovery step takes precedence over a global recovery step. Note that the 1st parameter to pass to the recovery step should be the exact name of the step to which you want to add recovery.
Element offers the ability to control what happens after a step has been recovered. By returning one of these instructions, the test will change its course.
RecoverWith.RETRY: Run the previous step again. Element will only do this up to the
triescount, which is
1by default. You can apply a general value for the whole test by putting this option within the
TestSettings, or override this value for a specific step by putting it into the recovery step as in the code snippet below.
RecoverWith.CONTINUE: Continue to the next step. This is the default behaviour.
RecoverWith.RESTART: Exit this loop and restart the test at the beginning, resetting the browser in the process.
#Which recovery method should you use
The best recovery method to use depends on whether you want the recovery time measured separately from the step you were testing.
try/catch will include the catch time in the total step time.
Using a recovery step will measure the time separately as "Step 1 (Recovery)".
Flood Element supports conditional execution. If you want to execute a specific chain of actions only when a condition is satisfied, you can do so using either
Execute only when a condition is met.
Execute only when the opposite of a condition is met.
To repeat a step a certain number of times or while a condition is still true, use
Repeat a step for a predefined number of times.
Repeat a step while a condition is true.
#Run a step once
Run a step only once in the whole test regardless of the number of iterations. This can be used to create setup and teardown steps. For example, you can run an authentication step at the start of the test and a logout step at the end.
Mark a step as
Skip the execution of a step in your test. Skipping a step is a little like commenting it out, but the step will be shown in the execution as skipped.