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

# Test Sets

> Define the scenarios you want to evaluate your agent against.

A **test set** is a collection of **test cases**, and a test case is one scenario you want to evaluate your agent against — a goal the simulated user pursues, like "get a refund" or "reschedule an appointment." When you launch a simulation, Coval runs each test case as a conversation and scores the result against your [metrics](/concepts/metrics/overview); the test set aggregates the outcomes across all its cases.

## What test cases let you do

A test case is how you tell Coval *what* to put your agent through. A good set of them lets you:

* **Cover the scenarios that matter** — happy paths, edge cases, and known failure modes, one test case each.
* **Catch regressions** — re-run the same test set after every change to confirm nothing broke.
* **Test across user types** — run the same test set with a different [persona](/concepts/personas/overview) (one per run) to see how your agent holds up with different kinds of users.

<CardGroup cols={2}>
  <Card title="Create a test set" icon="circle-plus" href="/concepts/test-sets/create">
    Generate test cases with AI, build them manually, or upload a CSV/Excel file.
  </Card>

  <Card title="Input types" icon="list" href="/concepts/test-sets/input-types">
    Scenario, transcript, audio, script, or image — how tightly the simulated user follows your input.
  </Card>

  <Card title="Expected behavior & attributes" icon="ballot-check" href="/concepts/test-sets/evaluation">
    Define how the agent should respond and attach per-test-case data for evaluation.
  </Card>

  <Card title="API" icon="square-terminal" href="/api-reference/v1/test-sets/test-sets/create-test-set">
    Create, list, update, and delete test sets programmatically.
  </Card>
</CardGroup>

## Test case inputs

The **Simulation Input** is the heart of a test case: it becomes the simulated user's objective for the run. The input type determines how tightly the simulated user follows it — from improvising toward a high-level goal to delivering exact lines:

| Type           | What it is               | Simulated user behavior               |
| -------------- | ------------------------ | ------------------------------------- |
| **Scenario**   | High-level intent        | Improvises freely toward the goal     |
| **Transcript** | A reference conversation | Adapts as needed to match the flow    |
| **Script**     | Exact turns              | Follows them precisely, word for word |

See [Input types](/concepts/test-sets/input-types) for how each behaves and how to configure it. You can also attach an [image](/concepts/test-sets/input-types#image-attachment) (WebSocket voice agents only) or a [pre-recorded audio file](/concepts/test-sets/input-types#audio-upload) to a test case.

## Recommended test set types

<Info>
  For comprehensive testing, create multiple types of test sets:

  * **Regression Set**: Contains "happy path" scenarios representing typical successful interactions
  * **Adversarial Set**: Contains edge cases and scenarios designed to test your agent's limits and handling of unusual requests
</Info>

## Test case vs. persona

A test case defines **what** the simulated user is trying to accomplish; a [persona](/concepts/personas/overview) defines **who** they are — their tone, accent, and behavior. The same test case can run with any persona, which pursues the test case's goal in its own style. To make the simulated user attempt a specific (or adversarial) request, put it in the test case's Simulation Input — the persona only shapes *how* the user behaves, not *what* they're trying to do.

A run executes over multiple test cases, but only one persona.

## Version history

Every config-changing save of a test set is recorded in its version history — capturing both the test-set configuration **and** a snapshot of its test-case grid — so you can see how the test set changed over time and tell which version a run used. See [Versioning](/concepts/versioning/overview) for how copy-on-save works and how to pull the history through the [v1 API](/api-reference/v1/test-sets/test-sets/list-test-set-versions).