Different and helpful uses of Rainforest Step Variables

Step Variables are used to inject custom and dynamic info or data into test steps. While Rainforest provides Built-in Step Variables like {{random.address_zip5}} which populates a 5-digit zip code when the test is executed, they can be used creatively to meet the needs of various situations. Here are a few of the more common special uses:

String Variables to together to create longer character strings:

Virtually any two or more different step variables can be strung together to create a longer string.

For example, {{random.address_zip5}} can be combined with {{random.first_name}} to produce "{{random.address_zip5}}{{random.first_name}}" which would populate as something like "19345Alice".

This is helpful for creating unique names for elements on a page the tester is tasked with creating to writing out a random message that can be identified by the tester later on in the test.

Using variables to create static unique email addresses:

There are some workflows that require a tester to have access to multiple email addresses to test completely. {{random.email}}, which is typically used to provide a tester with a randomly generated email, will provide only a single email. For workflows that require that 2 or more different email addresses, it is possible to create a second email for a tester's use by stringing together two or more step variables.

To define an email, two or more step variables can be combined together without spaces with an "@e.rainforestqa.com" like "{{random.last_name}}_{{random.password}}@e.rainforestqa.com" to produce something along the lines of "Rockman_y2ehSMZ6@e.rainforestqa.com".

You can then have testers access this inbox by asking them to go to the URL, "http://e.rainforestqa.com/{{random.last_name}}_{{random.password}}" which would populate something like "e.rainforestqa.com/Rockman_y2ehSMZ6".

Using variables for negative testing

Negative testing makes sure your app handles uncommon inputs correctly.

Imagine your sign in flow calls for a password 6 characters long and containing some special characters such as an underscore, or hash sign. If it doesn't meet this criteria, a warning flashes.

In this situation, to test out whether the warning properly triggers or not, you can instruct a tester to enter {{random.number}} (which produces a 9 digit numeric character string) into the password field and verify that the warning was triggered properly. Using a step variable provides a measure of confidence since testers may be entering different values

Did this answer your question?