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

# Building a test suite

> Tests, turns, checks, and runs: define a scenario in bulk, execute it against an environment, and search runs for what failed and since when.

A test is a conversation you wrote down, together with the assertions that must
hold when it runs. Run it after a change and anything you broke fails right
there, instead of turning up in production a week later.

## Four resources, one idea

| Resource       | What it is                                                  |
| -------------- | ----------------------------------------------------------- |
| **Test**       | the scenario: a named conversation you want to keep working |
| **Test turn**  | one exchange inside it, in order                            |
| **Test check** | an assertion about what the agent should do                 |
| **Test run**   | one execution of a test, and its result                     |

A test is the container. Turns are the script. Checks are what must be true.
Runs are what happened each time you executed it.

Turns and checks are managed independently of the test, so you can add a check
to an existing scenario without rewriting the conversation, or extend the
conversation without touching the assertions.

## Creating a suite

Each resource has a `batch` endpoint, which is what you want when defining a
suite from a file rather than clicking through it:

```bash theme={null}
curl -X POST "https://realtime-api.voiceflow.com/v1/stable/test/batch?projectID=$VF_PROJECT_ID&environmentAlias=main" \
  -H "Authorization: Bearer $VF_PAT" \
  -H "Content-Type: application/json" \
  -d '{ "data": [ ... ] }'
```

## Reading results

Runs are searchable rather than merely listable, so the useful question is not
"what ran" but "what failed, and since when". Search runs, then fetch the ones
you care about.

## How this differs from evaluations

These are different jobs and it is worth keeping them apart.
QA replays conversations *you* wrote and fails when the agent stops behaving as
decided. [Insights](/api-reference/sections/insights) scores conversations *real
users* had, and tells you how it is going. One protects against regressions; the
other finds things you did not think to test.

## Where to go next

Run tests against a cloned [environment](/api-reference/sections/publishing)
before merging into `main`, so a failing check blocks the change rather than
reporting on it afterwards.