An assertion is a logical expression that captures an expectation about the state of an application screen.
Waldo supports several kinds of assertions:
A box assertion verifies that a specific section of the screen renders correctly.
A text assertion verifies that a specific element on the screen displays a specific text.
A screen assertion verifies that the overall screen meets certain criteria.
During test replay, assertions serve two important purposes:
- They enforce that the application is behaving correctly and allow tests to have both functional and UI coverage for your app.
- They can help determine when a screen has properly loaded, because they give Waldo context around elements of the screen should be present before attempting an action.
The power of assertions
Assertions are a powerful tool in Waldo that you can use to identify potential regressions in your build. Waldo does not limit the number of assertions you can assigned to a flow. We recommend using assertions as often as necessary.
If an assertion fails, your test run will show as a failed run. However, a failed assertion will NOT necessarily stop the test from continuing to run or progress.
A failed assertion does not always mean your test will stop
Since Waldo is more intuitive than a script, it will still attempt to find the correct element and perform the right interaction to progress a test. Only a failed interaction will stop a test from advancing, because Waldo will be unable to progress to the next screen.
To understand how to best recover from failing assertions visit Fixing Assertions
With scripts, you can implement a wait time command. This is an extremely rigid approach, because it means the test can fail due to network speed and other variables.
In Waldo, we have two ways to address this that can be used in combination to provide more flexibility than a scripted wait time command.
1. Step Load Time
- Step Load Time simply says “this step should validate within a reasonable timeframe” and allows you to dictate that timeframe.
- Assertions allow you to specify the important aspects or elements that must be present on the screen to preserve desired functionality.
How Waldo makes a decision
Waldo determines the right time to perform an interaction by either:
- Waiting for all assertions to pass
- Waiting to hit the time limit
Whichever comes first will trigger and guide Waldo’s decision.
Let’s say that you have a button that needs to load on the screen, and that button allows you to logout of your account.
If the button is present on the screen, but has a loading icon in the middle of it instead of the words “Log Out”, Waldo may try to click on the button too early.
- Waldo recognizes that the button is present, but is not quite as smart as an end user who would realize the button is not clickable as it is loading.
Waiting won't solve the issue
The problem here is not wait time related. The actual problem is that Waldo is only taught to recognize the button is loaded on the screen. It needs to be given more specific success criteria so that it can learn when to attempt clicking on the button.
You can fix this by simply adding a text assertion that tells Waldo to not only look for the button, but to only attempt clicking on it when the words “Log Out” are present.
For more examples
Check out Waldo Academy: a new series of courses and product use cases designed to give users an in-depth understanding of Waldo to get more value out of their test suite.
Updated 2 months ago