Validations are typically about something visible on the page. There are many different types of validations you can use with the “check” command.

check that page contains "error message"

You can also perform negative validations.

check that page doesn't contain "error message"

The keywords verify, assert, validate, and assess are all alternatives to check.

Many times, there are several instances of the element we want to validate and we need to pinpoint a specific one with relative locations. These work the same way with validations as with clicking.

check that page contains "error message" below "Password"

We can use multiple relative locations if necessary.

Sometimes, the string being validated changes dynamically each time the test case is executed. If the string is supposed to have the same pattern each time, we can use testRigor’s template system: For example, if we need to validate a phone number number, we can use the following:

check that page contains simple template "###-###-####"

If the pattern is not identical but similar with reasonable variations like the amount of digits in the string, we can use RegEx to validate. For example, if we need to validate a series number that has between 9 and 11 digits, we can use the following:

check that page has regex "[0-9]{9,11}"

testRigor can validate CSS properties of elements and divs such as text color, background color, font, etc

check that property of "background-color" of "my-div" is equal to "rgba(0,0,0,1)"

By default, testRigor uses soft validations, which means that a test case will not fail if the validation fails but will continue to execute steps until it is no longer possible or until the test case is completed. This was designed this way in order to allow users to collect as many issues with a single flow as possible and to prevent triggering a scenario where the case stops on a validation only to find that the next step is also a failure. However, it is possible to use hard validations by appending the phrase and stop test if fails to your regular validation.


As you may have noticed in the CSS example above, validations can also be used on specific elements or divs and not just the full page. The image below exemplifies this more explicitly. In this case, the div menu replaces the full page in the validation.

check that "menu" contains "Request a Demo"

In addition to page-level, div-level, and element validations, testRigor allows validations to be performed directly against variables. However, since testRigor is always looking at the UI for validations, in order to perform a validation against a variable, we must use the keyword itself:

call api "" and save it as "variableName"
check that stored value "variableName" itself contains "James"

As shown in the example above, one of the most common instances where we see validations against variables is when validating API results. However, this can be used in any scenario where the validation or condition is based on what the variable itself is and not whether or not it is present in the UI. For example, the condition below is based on what the variable is instead of its presence or absence on the screen.

If stored value "variableName" itself is equal to "James" then
   enter stored value "variableName" into "First Name"
   click "Send"


Validations can be grouped into 3 different categories: UI only, UI & variable, Page & URL
UI only validations UI & variable validations Page & URL validations
  • has value/doesn’t have value (for inputs/text areas)
  • is checked/is not checked (for checkboxes/switches)
  • is disabled/is enabled
  • is visible/is invisible
  • color is
  • is clickable/is not clickable
  • cursor is
  • has CSS class
  • background color is
  • has property
  • has option selected
  • contains/doesn’t contain (text)
  • has regex/doesn’t have regex
  • is blank/is not blank
  • matches regex/doesn’t match regex
  • is equal to/is not equal to
  • is equal as a number to/is not equal as a number to
  • is greater than
  • is greater or equal than
  • is less than
  • is less or equal than
  • page’s return code is
  • title is
  • title contains
  • url is/url is not
  • url contains/url doesn’t contain
  • url starts with/url doesn’t start with
  • url ends with/url doesn’t end with
  • url matches regex/url doesn’t match regex
Remember that variables can be concatenated with each other or combined with static values:
check that url matches regex from the string with parameters "${homePrefix}/product/${type}/[0-9A-Za-z\-]+"

For full documentation and examples of variables, click here.

Screenshot behavior with validations

It is important to understand that individual validations do not prompt screenshots. A screenshot will be taken of a validation if it is the final step in a test case, but that is by virtue that it is the final step of the test case and not because of the validation per se. As a rule of thumb, screenshots are prompted on commands where the viewport is expected to change. See Click, Drag, Hover for prompting screenshots where they would not normally be taken.

See the section on scrolling for information about how auto-scrolling affects validations.

Test your knowledge

check that url has "" in link
check that url contains ""
verify that "" is inside the url
check that url starts with ""
check that page contains a dynamic sting between 6 and 8 characters
check that page contains a series of numbers with 6 to 8 characters
check that page contains simple template "#######" or "#######" or "########"
check that page contains regex "[0-9]{6,8}"
check that page contains message "Sign up successful"
check that page contains "Sign up successful"
check that page contains message "Sign up successful" as expected
verify that page displays "Sign up successful"