Text Assertions can be used to ensure a UI element exactly matches or contains a given text snippet.
Text Assertions can also be used to specify when an element, like a button, is ready to be clicked as seen in the Step Load Time example from our main Assertions article.
Any Text Assertions should be deterministic
If a word appears multiple times on the screen, or in multiple variations, it is not a great candidate for a deterministic Assertion as it will not help Waldo narrow in on where to go or what to do.
Why would I want to use anything other than "Text Equals" when building a Text Assertion?
Let's use the example of the Sign Out button referenced above (and in the main Assertions article). Sometimes elements like buttons take a little while to load. Telling Waldo to wait for specific text to appear on the button trains the platform that the presence of the button itself does not necessarily mean it is time to attempt an interaction.
However: UI changes may impact that specific text over time.
v1 of your application had a button populate with the words "Sign Out" and v2 of your application has it populate with the words "Log Out".
If you built a "Text Equals" assertion here programmed to look for only "Sign Out", the v2 would fail that assertion.
However, since you know the button will always (at least for the sake of example) contain the word "Out", you could simply build a "Text Contains" assertion that is programmed around the word "Out".
This way, you could use "Log Out", "Sign Out", or even "Peace Out" without failing the assertion.
Updated 12 months ago