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

# What is a test?

A test describes one scenario and the behaviors you expect from your agent. It selects one or more personas to act as the caller. You can also supply mock tool responses and Env fields for  each test to be passed along during the test.

For example, a 'booking test' can ask the caller to request an afternoon appointment and require the agent to check availability before offering a time.

## Parts of a test

### Scenario

The scenario tells the caller what they want and how to act in this conversation. Describe one situation in plain language. Keep unrelated situations in separate tests. For example - a scneario could be 'You have an upcoming appointment and want to change it'

### Expected behaviors

Expected behaviors are observable requirements for your agent. Include at least one. The Expected behaviors grader checks these statements against the simulation's evidence.

For example: “The agent asks the caller to confirm the appointment date and time before booking.” Use one clear claim per behavior.

### Personas

A [persona](/docs/platform/personas) defines the kind of caller. The scenario defines what that caller wants in this test. Select one or more personas. Each selected persona adds a simulation when you run the suite. Typically personas represet callers with differnt personalities like interruptive, angry or they could talk in a different language like Spanish etc.

### Mock tools

Mock tools provide a fixed response or error for a named tool. For example, make an availability tool return no appointment slots. A tool without a mock runs its real implementation.

See [Mock tool responses](/docs/platform/tests/mock-tool-responses) for examples and supported connections.

### Env

**Env** represents startup context. These fields are passed to the connection before the conversation starts. For LiveKit, `job_dispatch_metadata` supplies the JSON data your worker reads from `ctx.job.metadata`. For Retell, `retell_dynamic_variables` supplies string values.

This is the **Env** field in the UI and the `## Env` section in a test file. It does not set shell environment variables or store credentials.

## Create a test

Follow [Create a test](/docs/platform/tests/create-a-test) for UI steps and CLI commands.

## Test suite

Each test is part of a [test suite](/docs/platform/tests/test-suites) by default.

## Run your tests

Running a test means running the [test suite](/docs/platform/tests/test-suites) associated with it. A [run](/docs/platform/runs/overview) executes the complete suite against one agent connection. Each test and selected persona combination produces a simulation. Two tests with two personas each produce four simulations.

[Start a run](/docs/platform/runs/start-and-follow-a-run), then inspect each simulation's conversation and grading results. The same suite can run against different connections, so you can check a flow through both text and voice.

## Keep your tests current

Add tests as you add flows and capabilities to your agent. Keep tests for working behavior in a regression suite, and use a separate suite for behavior you are still improving.

If you edit tests in both the UI and your repository, run `egma pull` before local edits and `egma push` when they are ready. See [Test suites](/docs/platform/tests/test-suites#keep-local-and-browser-changes-in-sync) for synchronization and conflict handling.