Using variables in UI tests

This article assumes you've already built a test. If you haven't, start with Creating your first UI test with Automated Testing.

Why use variables?

When you record or build a UI test, the values you type (a lead name, a company, a phone number) are captured as literal text. That works fine for a one-off run, but it causes problems when the same test runs repeatedly:

Records with uniqueness constraints fail on the second run.
Your org fills up with identical test records.
Date-sensitive logic can't be validated against "now".

Variables solve this by generating a fresh value every time the test runs. Named variables also let you reuse the same generated value across multiple steps, so you can type a random Last Name in one step and assert on it later.

Inserting a variable

You can add variables to any step that accepts text input, including assertions. To do this:

Click the pencil icon on the step to open it for editing.
Put the cursor where you want the variable, then type {.
A dropdown appears listing the available variables, grouped by category. Pick the one you want.

Naming a variable to reuse it

After you pick a variable, Gearset asks whether you'd like to name it:

Giving the variable a name stores the generated value so you can use it again in later steps. Named variables show up at the top of the dropdown under Your variables whenever you type { in a later step.

If you skip the naming prompt, the variable is inserted as a one-off. Each reference generates its own independent value. Use this when you don't care what the value is, just that it's random.

Example

In the test below:

Step 4 types Random Last Name into the Last Name field and is named Name.
Step 5 types Random Company into the Company field with no name, because the value is only needed once.
Step 7 asserts that the lead record header shows the text Lead and the reused Name variable.

When the test runs, Gearset generates a single last name (for example, Lowe) and uses it in both step 4 and the step 7 assertion. A separate random company name is generated for step 5.

Available variables

People

Random Email: a random, well-formed email address. Useful for lead, contact, and user records, or any field with email format validation.
Random First Name: a random first name. Useful for contact, lead, and user records.
Random Last Name: a random last name. The Last Name field is required on leads and contacts, so this is often the first variable you'll reach for.

Text & Numbers

Random Text (6): a random six-character string. Useful for fields with a strict length limit, short codes, or SKUs.
Random Text (8): a random eight-character string. Same use cases as Random Text (6) where you need a slightly longer value.
Random Number: a random number. Useful for numeric custom fields, quantities, or amounts.
Unique ID: a unique identifier, guaranteed not to collide with a previously generated one. Ideal for fields with a unique constraint where Random Text might eventually clash over many runs.

Business

Random Company: a random company name. Useful for the Account Name field, Company on leads, or any text field representing an organization.
Random Phone: a random phone number. Useful for phone fields with format validation.
Random Website: a random website URL. Useful for the Website field on accounts or any URL field.

Location

Random Address: a random street address.
Random City: a random city name.
Random State: a random state.
Random Postal Code: a random postal or ZIP code.
Random Country: a random country.

Location variables are generated independently. If you use Random City and Random State in the same step, they won't necessarily match geographically. If you need a consistent, realistic address, hardcode it or use a single Random Address and accept that geographic accuracy isn't being tested.

Date

Last Year: a date from the previous calendar year.
Last Week: a date from the previous week.
Today: today's date.
Next Week: a date in the following week.
Next Year: a date in the next calendar year.

Date variables are particularly useful for testing date-dependent logic. For example, you can check that an Opportunity Close Date in the future doesn't appear in a "closed this quarter" report, or that validation rules fire correctly on past dates.