> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testsprite.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Plan Generation & Editing
> How TestSprite turns discovered endpoints into a structured test plan, and how to review, prune, refine, and add to it before generation runs.
## What Plan Generation Does
For every endpoint that survived [API Discovery](/web-portal/core/api/api-discovery), TestSprite's testing agent produces a **structured plan**: test cases grouped by use case, each with a title, description, expected behavior, and priority. You can read, edit, prune, and add to the plan **before** any tests are generated, which is the cheapest place to catch a misunderstanding.
```mermaid theme={null}
flowchart LR
A[Endpoints known
from API Discovery] --> M[Feature map
features · use cases] --> B[Plan Generation]
B --> C[Structured plan
use case · title · description
expected behavior · priority]
C --> D{Your review
edit · prune · add}
D -->|Run all| E[Runnable tests]
```
**Nothing executes during plan generation.** No HTTP calls are made to your API at this step.
## What Goes Into the Plan
| Input | Where it comes from | What plan generation does with it |
| :- | :- | :- |
| Feature map | [Test Coverage](/web-portal/core/working-with-test/coverage-map) | Groups and scopes the tests by use case |
| Discovered endpoints | [API Discovery](/web-portal/core/api/api-discovery) | One sub-plan per endpoint, with shape-appropriate tests |
| PRD / docs upload | New Project form | Anchors the description and asserted behavior in what the endpoint is *for* |
| Response shapes from discovery | Discovery phase | Used as ground truth, so tests reference real field names |
| Extra Instructions | New Project form | "Skip the admin endpoints", "Always assert response time \< 200ms"; these get woven in |
## The Plan Structure
Each endpoint gets a **sub-plan** covering the categories of tests that fit what it does. Common ones:
* **Functional / happy path**: valid inputs, expected response shape, basic error paths (404, 400 on bad input)
* **Authorization & authentication**: unauthenticated → 401, wrong-user → 403, ownership checks, token handling, signature tampering
* **Error handling & edge cases**: missing required fields, malformed input, type coercion traps, unicode / null / encoding edges
* **Boundary & load**: oversized payloads, max array lengths, rate-limit edges, concurrent-write contention
* **Security probes**: privilege escalation, common attack patterns relevant to the endpoint
Not every category applies to every endpoint. A small CRUD endpoint might get 3–8 tests; a complex endpoint with security implications can get 15+.
## Reviewing the Plan
Click Plan Tests on **Test Coverage** and TestSprite's testing agent plans the tests. They open in **Review proposed tests**, grouped by use case; pick a use case on the left to see its tests.
Each row shows the test title and a short description. Click the row body to expand it.
The checkbox on each row controls whether the test is generated. A use case's **Select All** checkbox toggles all of its tests.
Click the title to rename it, or the description to edit it. Your edits shape the generated test.
Each test has a priority, and higher-priority tests run first. Reorder if there's a flow you want verified before everything else.
On a first run, keeping everything selected is usually right. If a use case has more tests than you want, untick individual low-value ones rather than the whole use case.
## Adding Tests in Natural Language
Click + More Test Case for \ below the list to add a blank row, then write its name and description in natural language. TestSprite generates the test from what you write. Added rows work like the others: you can edit, prune, or reorder them.
```text Targeted addition theme={null}
POST /orders with quantity=0 is rejected with a 400.
```
```text Domain-specific edge theme={null}
POST /users with an email already used by another user returns 409 Conflict, not 200.
```
## What "Run all" Actually Triggers
Clicking **Run all** (or **Run N tests**) adds the selected tests and starts generating and running them. The plan is locked in at that point; later edits require regenerating. Next: [Endpoint Tests](/web-portal/core/api/endpoint-tests).
## When Plan Generation Looks Wrong
Discovery didn't fully observe this endpoint's response, so the shape was inferred from your docs. Correct the test description to match the real shape, and generation will follow your edit.
Either the endpoint wasn't in the discovered set ([revisit Discovery](/web-portal/core/api/api-discovery)), or the test was judged redundant or out of scope. Add it yourself with + More Test Case.
Give more domain context in **Extra Instructions** (in **Project Settings → General**) or a richer PRD, e.g. "orders have a status enum: pending, confirmed, shipped, delivered, cancelled".
Untick the security tests in the review. The default sizing assumes external exposure; for internal services 1–2 auth checks are usually enough.
The endpoint was discovered but judged unsafe to test (missing auth pattern, unclear response shape). Add the test yourself with + More Test Case.
## Where to Go Next
The next phase: turn the plan into runnable tests
Auto-assembled multi-step chains
Natural-language refinement after tests are generated
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.