Tests
On this page
Tests
A complete test suite derived automatically from your acceptance criteria — one criterion, one test. · Recommended
The Tests tab is a live window onto your spec: every acceptance criterion becomes exactly one test row, updated the instant you edit the criterion. There's no "generate tests" step and nothing to keep in sync. Skip this tab if you only need a PRD, but it's what makes the handoff to a coding agent test-first.
How tests are derived
Each criterion maps mechanically to one test row:
| Test field | Comes from |
|---|---|
| Given / When / Then | The criterion's BDD clauses, verbatim |
| Scenario (happy / edge / error) | The criterion's scenario category |
| Status (draft / passed / failed / …) | The criterion's status |
| Role | The persona on the parent user story |
| Reference ID | A stable T-{story-slug}-{position} identifier |
| Type (unit / integration / e2e) | Classified automatically from the language of the Given/When/Then |
Because the relationship is one-to-one, you never edit a test directly. To change a test's content or status, edit the underlying acceptance criterion in the Features tab.
The reference ID
Every test has a short, stable ID like T-use-remember-me-option-2 (the second test under that story). It survives reordering, is short enough to drop into chat, and doubles as a default filename — VibeMap suggests {feature-slug}/{ref}.spec.ts when handing off.
Automatic type classification
Each test is tagged unit, integration, or e2e from its wording:
- UI verbs (click, view, page, navigate, toast, button, displayed) → e2e
- Data/network verbs (record, database, API, request, email, webhook, inserted) → integration
- Anything else → unit
It's a hint, not a contract — your coding agent can override it when scaffolding real files.
Browsing the suite
The filter bar narrows the visible tests by feature, persona, scenario, type, status, or priority, plus free-text search across ID, story, feature, and the Given/When/Then. Filters combine, and a passed/total counter reflects the current set. Click any row to open a side panel with the full context, the suggested filename, and a jump to the underlying criterion.
⚡ Power-user hints
- Improve tests by improving criteria. Missing error/edge tests? Generate more of those scenario types on the story. Vague test name? Sharpen the criterion's clauses. Wrong type? Reword to use clearer UI vs. data vocabulary.
- The blueprint carries the suite. The Atomic Blueprint export includes a top-level
tests[]array with asuggested_filenameper test; agents like Cursor and Claude Code read it directly and scaffold test files alongside implementation.
💡 Tip: A story with only happy-path criteria produces only happy-path tests. Use the scenario filter to spot stories missing error and edge coverage at a glance.
↔ The traditional way
Test plans are usually written by hand in a separate doc, drift from the spec within a sprint, and are the first thing dropped when time is short. Here the suite is the spec — it can't drift because it's a projection, and it arrives at handoff already structured for a coding agent to implement test-first.
What's next
- Hand the suite to your coding agent → Prepare for Dev
- Give pages and schema more context first → Generating Pages