Generative AI-Based Testing Certification
Validations
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.
Categories
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 "https://testrigor.com" 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"
end
UI only validations | UI & variable validations | Page & URL validations |
---|---|---|
|
|
|
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.