testRigor Best Practices

There are several best practices you can follow to make your tests more stable, reliable, and easier to deal with.

Overall, generic test automation best practices are discussed here. We will get into more details related to testRigor usage.

When building tests, you want to make sure that your tests are:

  1. Repeatable
  2. Should end with a validation
  3. Easy to read and understand
  4. Must be written from end-user’s perspective
  5. Should have no duplicated code
  6. Independent from each other so that they can run in parallel
  7. Test data and specifically test credentials are stored in test data
  8. One testRigor test case for one test
  9. Use built-in testRigor functionality for better stability and performance

Make tests repeatable

To make tests repeatable, you want to make sure they would run multiple times, not just once. It can be achieved by generating and creating test data you need in your test within the test. To generate data, you can use generate command. Then you’ll be able to store the value of generated data in variables (stored values) and use it later in the test. It is advisable to use Reusable Rules to create data. You can name them something like Create New Lead like this:

click "Leads"
click "New Lead"
generate unique name, then enter into "First Name" and save as "generatedFirstName"
generate unique name, then enter into "Last Name" and save as "generatedLastName"
generate unique name, then enter into "Company" and save as "generatedCompany"
generate unique email, then enter into "Email" and save as "generatedEmail"
click "Create"
check that page contains "Created"

In this code above, the Create New Lead rule will create a new lead, save the data about the lead into variables for future use and wait until the create action is complete and confirmation that it had been complete is visible on the page making it possible to continue without any delays if further actions are performed on the newly created lead. It could be used in a test case like this:

login
...
Create New Lead
click "Leads"
check that table at the row containing stored value "generatedLastName" and column "Status" contains "Created"
click "email" on the right of stored value "generatedLastName"

As you can see above we relied on unique values of the generated data to keep the test repeatable every time and stable.

Tests should end with a validation

If you don’t have validation at the end of your test, you don’t know if your last action succeeded. For instance, if you clicked on a button, you don’t know if it worked or not. By adding validation at the end of the test, you’ll verify that what you expected to happen actually happened.

...
click "Submit"
check that page contains "Process successfully"

Tests should be easy to read and understand

To make your tests easy to read and understand, you should always try to use visible texts and create human-readable Reusable Rules.

...
enter "Peter" into "First Name"
enter "Gosling" into "Last Name"
click "Submit"
Process Submitted Contact

Additionally, test cases can be greatly improved by using comments to specify where a reusable rule is, what exactly this part of the test does and divide the test into distinct steps.

...
// Step 3
go to registration form // reusable rule

// Fill in registration form
// Step 4
enter "John" into "First Name"
enter "Doe" into "Last Name"

// Step 5
click "Register"
check that page contains "Registration complete"

Tests must be written from end-user’s perspective

This is the most important best practice of them all. Anything you create as a test must be done purely from end-user’s perspective, without relying on details of implementation as much as it is possible.

Specifically:
  1. You want to avoid using ids/css classes/etc as much as possible, because they can change at any point in the development. You can often rely on relative location as much as you can. Try to rely on sections like so: enter "149 New Montgomery" into "address" in the section "From"
  2. Also, you want to avoid relying on ids/names for inputs and rely on the labels (or placeholder text) instead
  3. In cases if it is not possible (you are clicking on an icon, for example), try to extract the part of CSS class that is the most descriptive of what this button does. For example, instead of click "btn-requester-list-grid-clear-filter" use click "clear-filter"

Tests should have no duplicated code

If you notice that you are about to copy-paste some code to another test or this code was already copy-pasted, create a Reusable Rule and use that rule instead of those lines of code as described in the section Making tests repeatable.

You should also search for existing Reusable Rules potentially already created by your colleagues before building a new one.

It is a good practice to start a Rule with validation to make sure it is applicable and fails early, as well as end it with validation to make sure that rule actually succeeded.

Always make sure that the rule name is as descriptive as it is possible.

Tests should be independent from each other so that they can run in parallel

Similar to what we talked about section Making tests repeatable, try to create the unique data used in the test so that all of your tests will be able to run in parallel. This will greatly benefit the performance of the test suite once the number of tests is large enough, and you’ll add more parallelization for the test execution.

There should never be any dependency between any test cases because they all might run in parallel. If you need to have some data generated or setup for other test cases, you should use reusable rules generating unique data, or, if data doesn’t need to be unique, use the test suite’s before-hook that you can edit on the top of test cases page in test suite hook section.

Test data and specifically test credentials are stored in test data

If you use some test data that might change in the future and/or any credentials, they should be stored in the test data section. This will allow you to hide passwords and easily update data in one place once it changes, even if it is used in multiple tests.

One testRigor test case for one test

Even though the test cases in your test case management system might be very large and all-encompassing, you should try to create as granular test cases in testRigor as it is technically possible to be able to run them faster and take better advantage of parallelization.

Tests should use built-in testRigor functionality for better stability and performance

Specifically:
  1. Use email functionality to check emails and extract data from emails
  2. Use login and other built-in testRigor reusable rules to allow you to auto-adapt to minute changes and keep your tests as stable as possible