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.
What Plan Generation Does
UI Plan Generation takes the Feature Exploration output — the live walks TestSprite did through your app — and turns each feature into a list of test cases grounded in real observed flows. The plan is the contract you review and edit before any test code is written.“Verify a new user can sign up with a valid email and lands on the welcome screen”— not a description of an internal endpoint or contract. The plan reflects how a user actually moves through your app.
Nothing executes during plan generation. No browser actions are issued. Plan generation is a pure read of: explored features + your description + extra-context hints + (Pro) your account-level UI conventions.
What Goes Into the Plan
| Input | Where it comes from | How it’s used |
|---|---|---|
| Explored features | Feature Exploration | One sub-plan per feature, with cases grounded in observed flows |
| PRD / extra context | Configuration step | Shapes what’s “in scope” vs “out of scope” |
| Test account credentials | Configuration step | Inform how authenticated paths get tested |
| Site map (Use Case Flow) | Built during exploration | Used as context — TestSprite knows which features connect |
The Plan Structure
Each plan row is one test case with a title, description, and priority. Plan generation also produces an underlying step list — concrete Actions (clicks, fills, navigations) and Assertions (what to verify) — that’s revealed per-row via a Show steps toggle.
Reviewing the Plan
The plan view is a flat list of cases. Each row shows checkbox · No. · priority · title · description, with a per-row toggle to reveal the underlying step list.Read the description, then Show steps if you need detail
The description is what drives generation. Click Show steps under the row to see the Action / Assertion list TestSprite will execute. Steps are read-only — adjust them by editing the description above.
Untick anything you don't want
Per-row checkbox toggles a single case. The header checkbox toggles Select All for the whole list.
Edit titles and descriptions in natural language
Both Test Name and Test Description are direct text inputs. Plain-text edits feed directly into generation.
Adjust priority if you want a case run first
Each row has a Priority dropdown (default Medium). Higher-priority cases run earlier when execution kicks in.
Adding Test Cases in Natural Language
The bottom of the plan list has a chat input. TestSprite parses the request, figures out which feature it applies to, and writes a new case row.
The added test gets grounded if the feature was explored. If exploration walked the Cart, the new “remove an item” test inherits the explored selectors and flow. If the feature wasn’t explored, the new case is spec-based.
Refining the Plan via Natural Language
Beyond Add-a-test, the chat panel supports broader refinements:
What “Generate Tests” Triggers
Clicking Generate Tests advances the wizard to the next phase. The plan is frozen at click time — subsequent edits would require a re-generation.UI Test Generation
Each plan case becomes a runnable Python + Playwright test
Plan Generation and Free-Plan Limits
Plan Generation is free for all plans
The credit cost lands at test generation (one credit per test) and exploration (counted against the 10-feature lifetime cap on Free, unlimited on paid).
Spec-Based Cases (Fallback for Unexplored Features)
When Feature Exploration couldn’t reach a feature — paywall, login failure, transient error — plan generation still produces a plan for it, but derived from your description and any extra context, not from a real walk. These cases are flagged with a Spec-based badge. Spec-based cases are best-effort:- They might be wrong about specific selectors or button labels (no observed flow to ground them)
- They might miss flows you actually have (only what you described made it into the plan)
- They still run. Generation produces real Playwright code; selectors are resolved against the live DOM at run time.
When the Plan Looks Wrong
A test is asserting on something that doesn't exist (e.g. a button labelled 'Submit' that's actually 'Save')
A test is asserting on something that doesn't exist (e.g. a button labelled 'Submit' that's actually 'Save')
An obvious feature has zero test cases
An obvious feature has zero test cases
Feature Exploration probably didn’t reach it (check the exploration summary panel). Either:
- Re-run exploration with a clearer test account or extra context
- Add cases manually via chat
Tests are too generic — they don't reflect our domain
Tests are too generic — they don't reflect our domain
Add domain-specific extra context: “Our checkout has a special ‘Express’ lane for returning customers — make sure tests cover that path”. Future runs incorporate it.
The plan has too many tests for a small feature
The plan has too many tests for a small feature
Untick the ones you find low-value. Plan generation errs on the side of coverage; you can prune to taste.
The plan ignored something I uploaded as a PRD
The plan ignored something I uploaded as a PRD
The PRD shapes the plan but doesn’t override exploration. If exploration didn’t walk the feature your PRD describes, plan generation falls back to spec-based — and your PRD wording may not have specific enough selectors to make the case work. Refine after generation.
Where to Go Next
Test Generation (UI)
The next phase — turn the plan into runnable Playwright code
Step-by-Step Walkthrough
What you’ll see during execution
Refining Tests
Natural-language adjustments after generation
UI Testing — Overview
Step back to the journey map