Write unit tests

Tests that check behaviour rather than restating the implementation. The constraint that matters is which cases to cover.

When to use it

Adding tests to code that has already broken in production, where you know roughly where the bodies are buried.

What it prevents

Coverage theatre. Without named edge cases, models write tests that restate the implementation — they pass, they prove nothing, and they break whenever you refactor.

The prompt

Write unit tests for the function below.

### Context
This function has been the source of two production bugs, both in edge cases rather than the happy path.

### Requirements
- Cover the empty input, a single item, and a value of exactly zero.
- One assertion per test, and a test name that states the expected behaviour.
- Do not mock anything that can be constructed directly.
- Output format: A single code block using Vitest.
- Avoid: tests that only restate the implementation, and tests added for coverage alone.

### Function
"""
function total(items) { return items.reduce((a, b) => a + b.price, 0) }
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Change the function and, critically, name the edge cases yourself — empty, single, boundary, the value that caused the last bug. The model cannot know which cases have hurt you in production; that knowledge is the whole value you add. Keep “one assertion per test” and “a name that states the expected behaviour”, so a failure tells you what broke without opening the test.

The mistake this prompt avoids

Asking for tests without naming cases, then getting tests that restate the implementation. They pass, they add a coverage number, and they prove nothing — worse, they break on every refactor because they assert how the code works rather than what it must do. Name the behaviours; let the coverage follow.

A variation

Adding a regression test for a specific bug? Skip the general suite and ask for one failing test that reproduces the exact reported input — before any fix. A test you have watched fail for the right reason is worth ten you assume are testing something. Write the fix only once red is red for the reason you expect.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.