Claude Code prompt: add tests to code that has none

Agents are quick to write tests that pass and check nothing. This work order asks for tests that would catch a real change. Claude picks the functions other code depends on most, lists the cases before writing them, records today's behavior (bugs included, flagged for you), and then breaks the code on purpose to prove at least one test notices.

The work order

Copy it, fill in the [brackets], and paste it into Claude Code. It also works in Cursor's Agent mode.

Add tests to untested code Claude Code · testing

[file or module path] has no tests, or almost none. Add tests that pin down what it does today. Don't change the code under test.

Test setup: [framework, e.g. pytest / Vitest / Go testing]. Copy the style of [an existing good test file]. Run tests with [command].

Before writing any tests:
- List the module's public functions or entry points, ranked by how much other code depends on them (check the callers).
- For the top [5], list the cases worth testing: normal input, edges (empty, zero, very large, unicode, missing fields), and error paths.
- Note anything that's hard to test without changing the code, like a hidden clock, network calls, or global state. Don't refactor it. Tell me, and work around it with the mocking approach this project already uses.
Show me the list and wait.

After I OK it:
- Write the tests. One behavior per test, with names that say what's being checked.
- Assert on real results, not just "doesn't throw" or "was called".
- If a test exposes behavior that looks like a bug, keep the test matching current behavior, mark it "current behavior, possible bug", and add it to a list for me.
- Run the new tests and show that they pass.
- Then change one line in the code under test on purpose, confirm at least one new test fails, and put the line back. Show that git diff for the source file is empty at the end.

Report: tests added, cases covered, cases skipped and why, and the possible-bugs list.

The deliberate break at the end is the quickest way to know the tests are real. A test suite that stays green when the code is wrong isn't protecting anything.

Variations

Variation 1: Raise coverage to a target Coverage

Raise test coverage for [path] to at least [target]%. First run [coverage command] and show me the current number and the uncovered lines.

Go after uncovered branches in real logic before getters and glue code. Don't add tests that run lines without asserting anything. Rerun coverage at the end and show the new number next to the old one.

Variation 2: A regression test before a bug fix Bug fix

We're about to fix [bug description]. Before touching the code, write one test that reproduces the bug and fails on the current code. Run it and show me the failure.

Stop there. We'll fix the code next, and this test should pass once we do.

Pairs well with the failing-test work order: write the red test here, then fix the code there.

Variation 3: Integration tests for an API endpoint API

Write integration tests for [METHOD /path] using the project's existing test client and setup (copy [example test file]).

Cover the happy path, missing and invalid fields, a request with no login, a request from a user who shouldn't have access, and the not-found case. Use the existing fixtures or factories instead of creating new data helpers. Run them and show the results.

When to use it

Code that matters has no tests, and you need to change it soon.
Before a refactor, so you can tell if behavior changed.
After a bug, to make sure that exact bug can't come back quietly.
Skip it for throwaway scripts. Put the effort where other code depends on you.

What good output looks like

A ranked list of what to test, approved by you, before any test code.
Assertions on actual values and side effects.
Tests that follow your existing test style and helpers.
A short possible-bugs list. Untested code nearly always has a few.
Proof from the deliberate break that the tests can fail, and an empty diff on the source file.

Common mistakes

Asking for "full coverage". You'll get many shallow tests and a nice number that means little.
Letting it "fix" bugs it finds while writing tests. Record them first and fix them as a separate change.
Allowing new test helpers and fixtures when the project already has them.
Skipping the approval step, so you get 40 tests for the least important function.
Mocking the very thing you meant to test.

Need a different prompt? Describe your coding goal and get ranked prompts with quality, match & confidence scores.

Rank prompts for my goal →

More Claude Code work orders

Related prompts in the library

FAQ

Why test current behavior if it might be wrong?

Because right now you don't know which odd behaviors other code relies on. Recording today's behavior gives you a baseline. The possible-bug flags tell you where to look, and you fix those as separate, deliberate changes.

What does the deliberate break step do?

It checks that the tests can catch a real change. Claude edits one line in the code, confirms a test goes red, and restores the line. If nothing fails, the tests aren't checking much, whatever the coverage number says.

Is a coverage target a good idea?

As a rough guide, yes. As the only goal, no. The coverage variation tells Claude to go after branches in real logic and not count lines that run without assertions.

Can Claude Code write tests for any language?

It works with whatever test framework your repo already uses. Name the framework and point it at a good existing test file so the new tests match your style.