Assertions are a fundamental component of testing; they help answer the question, "Is my application behaving as expected?"
At a high level, a browser or mobile test consists of the following:
- An action in the application under test, such as clicks, entering text, and visiting a URL.
- Assertion(s) to verify that the previous actions yielded the expected result.
For example, after taking the actions to log into an application, a good assertion would validate that these actions yielded the expected results. In this instance, after logging in, the assertion validates that the username appears on the page.
This article provides a high-level overview on recording and configuring assertions in the Trainer.
For more general guidance on creating assertions, see our article on assertion best practices.
Recording assertions
When you create an assertion, you define the logic mabl should use to confirm that your application is in the correct state at a specific step in a test run. In the mabl Trainer, you can make assertions against the following:
- Elements on the page
- The page URL - browser tests only
- Cookies - browser tests only
- Variables
- File downloads
Detailed information and steps for each type of assertion can be found in the links listed above.
Example of an element assertion
Assertions have a character limit of 300. If you are trying to assert on an element that has more than 300 characters, mabl will capture only up to 300 characters.
Configuring assertions
The following settings can be configured for element, variable, URL, and cookie assertions:
Disable case sensitivity
If you check "disable case sensitivity", mabl checks that the value matches what you expect without regard to what letters are in uppercase or lowercase.
For example, if your application displays names in all capital letters in some parts ("SMITH") and only partially capitalized in other parts ("Smith"), then case insensitive assertions could be used to validate the same name is being displayed in both areas.
The "disable case sensitivity" option may behave unexpectedly for certain characters and languages where casing exists and the rules differ significantly from standard English.
For example, some languages use the dotted uppercase I character "İ", which will not necessarily be considered equivalent to the dotted lowercase "i" with case sensitivity disabled.
Failure options
Indicate what should happen if the assertion fails:
Option | Details |
---|---|
Fail immediately | If the assertion fails, the test stops running and fails. This is the default option. |
Fail at end of test | If the assertion fails, the test continues running and is marked failed at the end. |
Continue on failure & mark warning | If the assertion fails, the step still passes and is marked with a warning. |
"Fail at end of test" and "Continue on failure & mark warning" are two implementations of a soft assertion. Soft assertions are useful for asserting non-functional aspects, such as element labels and style, without stopping the test from executing.
Behavior during Trainer playback
Failure options apply to local and cloud runs.
When playing steps in the Trainer, a failed assertion will immediately stop Trainer playback if it is marked "fail immediately" or "fail at end of test." Assertions marked "continue on failure & mark warning" always pass and never stop Trainer playback.
Lexicographic comparisons
If an assertion type involves a comparison - greater than, less than, greater than or equals, and less than or equals - and the assertion values cannot be interpreted as numbers, mabl orders the values according to their characters' Unicode code points. In this standard, the order of values from lowest to highest is as follows:
- Numbers (123...)
- Capital letters (ABC...)
- Lowercase letters (abc...)