Awesome Claude Prompts Unofficial

Write tests first, then implement

Have Claude Code write tests that describe a feature before any implementation, confirm they fail, then write code until they all pass.

Task: Write tests first, then implement · Other tasks

Fill in the details

Optional. Concrete inputs and expected results, especially the ones that are easy to forget.

Optional. Leave empty and Claude will find how the project runs its tests.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • You can state what the feature must do in concrete cases, and you want those cases written down as tests before the code takes shape.
  • The behavior has edge cases that are easy to get subtly wrong, such as expiry times, limits, permissions or repeated requests.
  • You want Claude to have a clear finish line: the work is done when the agreed tests pass, not when the code looks complete.

When not to use it

  • You are still exploring what the feature should do. Writing tests for requirements you have not settled locks in guesses; run a spec interview first.
  • The work is mostly visual, such as layout or styling. Unit tests say little there; compare screenshots against the design instead.
  • The code is existing and untested and you only want coverage for it. Use the unit test template, which covers code that already exists.

Why this structure

  • Tests come before implementation, as a separate numbered step with an explicit "do not write any implementation code yet". This keeps the tests describing the requirement rather than whatever the first implementation happens to do.
  • Step 3 asks Claude to run the new tests and show that they fail for the expected reason. A test that fails because of a typo, or passes before any code exists, proves nothing.
  • Step 1 points Claude at the existing tests, so the new ones use the same framework, file layout and helpers instead of a second testing style.
  • The rule against changing a test to make it pass protects the agreement you made in step 2. If a test is wrong, you hear about it and decide.
  • The full test suite run in step 5, with your command when you give one, gives Claude a pass or fail signal to iterate against and catches breakage elsewhere.
  • The mocks setting is explicit because it changes what the tests prove. Fewer mocks means tests that exercise more of the real code.

Example input (fictional)

Feature or behavior to build
The password reset flow: a user requests a reset link, the link works once, and it expires after 30 minutes.
Cases the tests must cover
An expired link is rejected. A used link cannot be used again. Requesting a link for an unknown address shows the same message as for a known one.
Test command
npm test -- auth
Mocks
Avoid mocks where a real implementation or a simple fake works

Follow-ups to send Claude

  • Show me the tests before you implement anything. I want to review the cases first.
  • Add a test for two reset requests in a row: only the newest link should work. Then make it pass.
  • Which parts of the implementation are not covered by any of the new tests?

Common mistakes

  • Letting implementation and tests be written in the same step. The tests then tend to confirm the implementation instead of the requirement.
  • Accepting failing tests without reading why they fail. The expected reason is "the feature does not exist yet", not an import error.
  • Describing the feature in general words only. Two or three concrete cases with expected results do more to pin down behavior than a paragraph of description.
  • Write unit tests: Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.
  • Write a spec by interview: Let Claude Code interview you about a feature, covering implementation, UX, edge cases and tradeoffs, then write a self-contained spec to a file.
  • Build something new from an existing pattern: Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.

See all templates

Sources