> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testorim.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Test data

> Tokens that generate fresh values, project variables, and values you supply mid-run.

A test that types `test@example.com` into a sign-up form works once. Testorim
substitutes `{{token}}` placeholders in a step's target and value at run time
so it works every time.

## Built-in generators

Always available, nothing to configure.

| Token               | Produces                          |
| ------------------- | --------------------------------- |
| `{{random.email}}`  | A unique email address            |
| `{{random.uuid}}`   | A UUID                            |
| `{{random.int}}`    | A random integer                  |
| `{{random.name}}`   | A person-shaped name              |
| `{{random.string}}` | A random string                   |
| `{{date.iso}}`      | The current date/time as ISO 8601 |
| `{{date.epoch}}`    | The current Unix timestamp        |

```text theme={null}
Sign up with {{random.email}} and the password Testing123!, then sign out and
sign back in with the same address.
```

<Note>
  **Each token resolves once per run.** The `{{random.email}}` typed during
  sign-up is the same address typed during sign-in later in the same run. That
  is what makes a round-trip test possible.
</Note>

## Project variables

Project settings → **Variables** defines your own tokens, used the same way:
`{{couponCode}}`, `{{accountNumber}}`.

A variable is either a fixed value or a generated one, such as a random integer within
a range, for instance. Like the built-ins, each one resolves once per run and
keeps that value for every step that references it.

<Warning>
  **Do not store secrets as variables.** Variables are stored as plain project
  configuration. Real secrets belong in
  [environment headers and cookies](/projects/environments), which are
  encrypted at rest.
</Warning>

## Values you supply mid-run

Some values cannot exist before the run does: a one-time passcode, an SMS
code, a CAPTCHA answer, a device-trust confirmation.

Ask for it in the instruction and the run pauses, shows you a prompt, and
continues with your answer:

```text theme={null}
Sign in with demo@example.com, then ask me for the 6-digit code from my
authenticator app and enter it in the verification field.
```

Later steps reference the answer as `{{prompt}}` (the most recent) or
`{{prompt:fieldName}}` when more than one was requested. The run waits up to 10
minutes.

<Warning>
  This needs a person watching. Scheduled runs, CI-triggered runs and fuzz
  variants have no input channel, so the step fails with that reason rather
  than hanging.
</Warning>

## Uploading files

Fixtures are files you attach to a project so a `type`-into-file-input or
`upload` step has something real to send. Reference the fixture by name in the
instruction: *"upload the sample-invoice fixture to the attachment field"*.

## Redaction

Values typed into fields whose name suggests a secret (password, secret,
token, PIN, OTP, CVV, SSN) are stripped before the run is persisted, before
the report model sees them, and before a shared link renders. That covers the
typed value, the value read back for verification, both sides of an assertion,
and any error or warning text that quoted it.

Identifier-shaped names are covered too: `userPassword`, `pwdField` and
`secretKey` redact, not just a bare `Password`.


## Related topics

- [Writing tests in plain English](/test-creation/writing-tests.md)
- [Create your first test](/getting-started/first-test.md)
- [Screenshots, logs and evidence](/test-execution/evidence.md)
- [Core capabilities](/introduction/core-capabilities.md)
- [Steps and expected outcomes](/test-creation/steps-and-outcomes.md)