4.4-tests

Tests

The Tests tab gives you a complete, structured view of every test your project needs — derived deterministically from your acceptance criteria. There is no separate "generate tests" step: every time you add or edit a criterion, the corresponding test row updates instantly. Nothing to write, nothing to keep in sync.

How Tests Are Derived

Each acceptance criterion in your project becomes exactly one test row. The mapping is purely mechanical:

Because the relationship is one-to-one with criteria, you never edit tests directly. To change the content or status of a test, edit the underlying acceptance criterion in the Features tab.

The Reference ID

Every test has a short, stable identifier of the form T-{story-slug}-{position}. For example, the second test under a story whose slug is use-remember-me-option is T-use-remember-me-option-2.

This identifier:

• Is short enough to use as a filename or in chat without taking up a line.
• Stays the same when other tests are added before or after it (positions are based on creation order, scoped to the parent story).
• Doubles as a default filename for downstream coding agents — VibeMap suggests {feature-slug}/{ref}.spec.ts when handing off to your IDE agent.

Automatic Test Type Classification

Each test is classified as unit, integration, or e2e based on the language of its Given/When/Then. The rules are simple:

• Mentions of UI verbs like click, view, page, navigate, toast, button, displayed → e2e.
• Mentions of data or network verbs like record, database, API, request, email, webhook, inserted → integration.
• Anything else → unit (pure logic, calculations, formatting).

This classification is a hint, not a contract. Your coding agent can override it when it scaffolds the actual test files.

Filtering and Browsing

The filter bar lets you narrow the visible suite by:

• Feature — show tests under a single feature only.
• Persona — show tests whose parent story targets a specific persona.
• Scenario — happy / edge / error.
• Type — unit / integration / e2e.
• Status — draft / ready / in progress / in review / passed / failed / blocked.
• Priority — high / medium / low (inherited from the parent story).
• Search — free-text match across the ID, story title, feature name, and Given/When/Then.

Filters combine. A passed/total counter at the top reflects the currently-filtered set.

Clicking a Test

Selecting any test row opens a side panel with the full Given/When/Then, the parent story's context, and the suggested filename. From the panel you can jump straight to the underlying acceptance criterion in the Features tab — that is the only place you can change a test's content or status.

How VibeMap Uses the Test Suite

Tests are surfaced everywhere your project hands off to a coding agent:

• The Atomic Blueprint export includes a top-level tests[] array. Cursor, Claude Code, and similar agents read this directly when scaffolding test files alongside implementation code.
• The blueprint includes a suggested_filename per test so your agent has a sensible default path.
• The MCP server exposes the blueprint via a single endpoint — no separate "list tests" call is needed.

Improving Your Test Suite

Because tests are a projection of acceptance criteria, the way to improve your tests is to improve your criteria:

• Missing scenario types? A story with only happy paths produces only happy-path tests. Generate more error and edge-case criteria from the Features tab.
• Vague test names? Make your Given/When/Then more specific. Each clause carries forward into the test row verbatim.
• Wrong test type classification? Tweak the Given/When/Then to use clearer UI / data / logic vocabulary, and the type updates automatically.

The Tests tab is a window onto your spec. The cleaner your spec, the better your tests.