Skip to content
STACK IT FIRST
Install the skills
Method skill · 02 While you build

Tests as spec

Turns a request into a failing test first, then implements until it passes and the full verify command is green - so the test is the spec the agent checks itself against.
v0.5.0 Updated

An agent cannot see whether its change is right; it can see whether a test passes. Write the test that describes the request before the code, and the agent has a definition of done it can check on its own.

When to use

  • Every bug fix: reproduce it as a failing test first.
  • New behaviour with a clear input and output.
  • Refactors: pin current behaviour with tests before moving code.

Skip it for pure copy or styling changes, where a test would only restate the markup.

Steps

  1. State the behaviour in one sentence: “Inviting an existing member returns 409 and sends no email.” If you cannot, ask the user.
  2. Find the right level. Use the cheapest test that exercises the real behaviour: a unit test for pure logic, a request test against the route for an endpoint, a component test for UI state, an end-to-end flow only for paths that make money.
  3. Write the test next to the code (or where the project keeps tests), using the project’s runner and helpers. Use a real database or the project’s test database setup, not mocks of your own data layer.
  4. Run it and watch it fail for the right reason. A test that passes before the change, or fails with an import error, specifies nothing.
  5. Implement the smallest change that makes it pass.
  6. Run the full verify command, not just the one test. Fix what it reports, including type and lint errors in code you touched.
  7. Tidy. Remove duplication you introduced, keep names honest, and make sure the test name reads as the sentence from step 1.

Rules

  • Never weaken, skip or delete a failing test to get green. If a test is wrong, say why and change it in a separate, visible step.
  • One behaviour per test. Several assertions are fine if they describe the same behaviour.
  • No snapshot tests for logic; snapshots are for rendered output that a human has reviewed.
  • Tests must not depend on order, wall-clock time or the network. Inject the clock and fake external services at their boundary.

Output

The test (shown failing, then passing), the implementation diff, and the verify command’s final result.