Assertions - Verify Response
When testing an API, it is usually not enough to verify that all our HTTP requests completed successfully. Often, it is necessary to make sure that we got the correct response from the server by examining the response status, body or headers.
With Loadmill, this is made easy by using Assertions. Assertions are used in conjunction with parameters to do just that: examine the server's response and assert its correctness.
You may have an arbitrary number of assertions executed after each successful request. If an assertion fails, the next request will not be executed and the test scenario will be marked as failed, but the subsequent assertions for the current request will be executed nonetheless.
Assertions editor can be found in loadmill under each request cubical on it's expanded form.

Assertion section in request editor
The target of an assertion is always a parameter value. You may use built-in parameters, default parameters or any parameter extracted from the current or previous requests in the current scenario as the target.

The request Assertions - Verify Response section
When using assertions, it will usually require to use extractions first to set the parameter with proper data and only then to attempt to validate it's form.
There are several types of assertions:
- Exists - Validates that a parameter exists and not null.
- Example 1: Assigning empty term to
param1
will result in assertion failure - Example 2: Assigning any value to
param1
will result in passed assertion
- Doesn't exist - Validates that a parameter doesn't exists or null.
- Example 1: Assigning any value to
param1
will result in assertion failure - Example 2: Not setting
param1
entirely will result in passed assetion
- Equals - Validates that a parameter is equal to the given expression. The equality check is case sensitive.
- Example 1: The assigned
param1
doesn't equals to loadmill hence will fail in assertion - Example 2: Extracting
$.args.app
json path field toparam1
(from the result that is not displayed) should be equal to "Demo" and will result the assertion to pass Assigning numeric value toparam2
of 11.0 in postscript should be equal to "11", and the assertion will pass.Note that all values are implicitly compared as strings.
- Doesn't equal - Validates that a parameter is NOT equal to the given expression. The equality check is case sensitive.
- Example 1:
param1
shouldn't be equals to 'demo' but it is, hence the assertion will fail - Example 2:
param1
doesn't equals to 'loadmill' hence the assertion will pass
- Contains - Validates that a parameter contains a sub-string. The containment check is case sensitive.
- Example 1: When
param1
set with the value 'loadmill-demo' and doesn't contains the string 'example' the assertion will fail. - Example 2: When
param1
set with the value 'loadmill-demo' and contains the string 'demo', the assertion will pass.
- Doesn't contain - Validates that a parameter DOESN'T contain the given expression. The containment check is case sensitive.
- Example 1: When
param1
set with the value 'loadmill-demo' and contains the string 'demo', the assertion will fail. - Example 2: When
param1
set with the value 'loadmill-demo' and doesn't contain the string 'example', the assertion will pass.