Test data that never collides: the unique token

The second time you run a sign-up test, it fails — not because the app broke, but because the email address the first run registered already exists. Any test that creates data hits this wall eventually. TestVibe solves it with a single token, {{unique}}, that hands every run its own values.

Why fixed data breaks

A test that only reads existing data is safe to repeat forever. Given the account has an invoice named "INV-1001" verifies something already there; it doesn't matter how many times you check it.

Creation is different. The moment a step registers an email, names a new project, or adds a record, that value is now taken. Hardcode it and you get two failure modes:

• Repeat runs collide. Run the test today and it registers casey@example.com. Run it tomorrow and the app rejects the address as already in use. The test fails on data left behind by its own previous run, not on a real regression.
• Parallel runs collide with each other. Two runs firing at once — a manual run while a scheduled automation is mid-flight, or two scenarios in the same suite — both try to create Project Alpha. One wins, one gets a duplicate-name error, and the failure looks random.

Both failures are noise. They tell you nothing about your app and they erode trust in the suite, because a green result now depends on remembering to clean up by hand between runs.

What the token does

Wrap any created value in {{unique}} and the collision disappears:

When the user signs up with email "casey+{{unique}}@example.com"
And the user creates a project named "Project {{unique}}"

{{unique}} expands to a fresh stamp at run time. Each run gets its own stamp, so the email your test registers today is different from yesterday's, and two runs happening at the same moment never land on the same value. The literal in your Gherkin stays readable — you can see it's an email, you can see it's a project name — but the actual value is generated per run.

Two properties make it dependable:

1. It's run-scoped, and stable within the run. Every occurrence of {{unique}} in a single run resolves to the same value. That's what lets a later step reuse what an earlier step created — sign up, then sign back in with the same address, or create a record and then assert its name appears in a list.
2. It takes no setup. No arguments, no variable to define anywhere. Drop the token into a value and it works.

Patterns that use it

Plus-addressing for sign-up. The +{{unique}} trick keeps every registration under one real inbox while giving each run a distinct address the app treats as new:

Scenario: New user signs up and lands on the dashboard
  Given I am on the "Sign up" page
  When the user signs up with email "casey+{{unique}}@example.com"
  And the user sets a password and clicks "Create account"
  Then the dashboard should open

Create, then act on what you created. Because the token resolves to one value across the run, an earlier step and a later step agree on it:

Scenario: A created project appears in the list
  Given the user is signed in
  When the user creates a project named "Project {{unique}}"
  Then "Project {{unique}}" should appear in the project list

The Then isn't guessing at a name — it references the exact value the When produced.

Unique names for records, teams, and uploads. Anything the app stores under a name benefits: a team, an invoice draft, an uploaded file. Wrap the name and repeated runs stack up cleanly instead of tripping over each other.

When not to reach for it

The token is for values your test brings into existence. It's the wrong tool in two cases:

• Referencing existing data. If a step points at a record that's already there — Given the account has an invoice named "INV-1001" — keep it a plain literal. Making it unique would point the test at something that doesn't exist. Stable, known records are exactly what you want for read paths.
• Credentials and secrets. A sign-in password or API key isn't a value you invent per run; it has to match what's configured. Those use {{var:NAME}} and {{secret:NAME}} tokens instead, resolved from your workspace variables and secrets rather than randomly generated.

A quick rule: if the step would fail when run twice in a row because the value is "already taken," it creates data — wrap it. If it would fail because the value isn't there, it references data — leave it literal.

The payoff

Uniqueness is what makes a generated test genuinely repeatable. Write the scenario once, and it runs today, tomorrow, on a schedule, and alongside a dozen parallel runs without manual cleanup between them — because no two runs ever ask for the same value. That reliability is the whole point: a suite you can trust to be green for real reasons.

Want tests like these generated from plain descriptions and verified by actually running them? Get early access, or read Write good test instructions for more on repeatable scenarios.