Add tests for an untested module
Backfill coverage against a named bar — not the agent's idea of 'enough tests'.
'Add tests' is one of the most-abused prompts in agent work. Without a bar, the agent ships three happy-path snapshots and declares victory. This template names the specific cases that must be covered, the structural template to imitate, and the runner command that has to pass.
When to reach for this template.
- You can list the specific cases that need to be covered (happy path, empty input, malformed input, the bug you hit last week).
- An existing test file shows the structural pattern to imitate.
- You want a measurable bar — a coverage threshold, a list of `it(...)` blocks, a specific failing case.
- You're willing to forbid changes to the module under test.
The template.
Drop this into .watchfire/tasks/<n>.yaml, edit the prompt and acceptance_criteria to match your repo, and let the daemon run it.
task_id: test0004
task_number: 4
title: "Add vitest unit tests for lib/parser.ts"
prompt: |
`lib/parser.ts` exports four functions
(`parseInput`, `parseHeader`, `parseRow`,
`parseFooter`) and currently has no tests.
Add a colocated suite at `lib/parser.test.ts`
using vitest 1.x — the existing runner
configured in `vitest.config.ts`.
Use `lib/format.test.ts` as the structural
template: same import order, same describe/it
nesting, same assertion style (`expect(...)`,
not snapshots).
For each exported function, cover:
- One happy-path case with realistic input.
- The empty-input case.
- The malformed-input case (assert the thrown
error type and message).
Do not refactor `lib/parser.ts` itself.
acceptance_criteria: |
- `lib/parser.test.ts` exists with at least 12
test cases (4 functions × 3 cases each).
- `npm run test -- parser` passes.
- `npm run test` (full suite) passes.
- `npm run lint` passes.
- No new dependencies; no changes to
`lib/parser.ts`.
status: ready
Common pitfalls.
The shapes of failure most often seen on this kind of task — and the way this template hedges against each.
- Saying 'add tests' without naming the cases. The agent writes three happy-path assertions and moves on; the regression you actually cared about stays uncovered.
- Not pointing at a structural template. The agent will invent its own test style, your repo gets two flavours, and `describe`/`it` nesting drifts.
- Letting the agent edit the module under test. It will 'helpfully' tweak the function to make the test simpler — and you'll never know the original behaviour wasn't the bug.
- Pinning coverage but not behaviour. A 90% threshold passes with assertions like `expect(fn).not.toThrow()`; name the actual outcomes you want verified.
Related templates.
Fix a bug
Hand the agent a repro and a narrow brief — and get back a fix, not a rewrite.
Open the template
Refactor / rename
A mechanical move kept mechanical — so the diff stays cheap to review.
Open the template
Performance regression hunt
Pin the threshold in the acceptance criteria — and make the agent prove it.
Open the template
Pair it with a playbook.
These use-case playbooks lean on tasks shaped like this one.
Build your own.
This template is a starting point. Fill in a form to draft your own task in the playground — or read the full task schema to learn every field the daemon understands.
Get started with Watchfire
Install in seconds. Define tasks. Let agents ship code for you.
Download for macOSAvailable for macOS, Linux, and Windows
# Install via Homebrew (macOS)brew tap watchfire-io/tapbrew install --cask watchfire-io/tap/watchfire# Set up your project and gowatchfire initwatchfire task add "Build the login page"watchfire start --allIncludes GUI, CLI, and daemon. Also available via Homebrew.