Guides / Developers

How do I find which tests my change is missing?

A prompt that lists each behaviour a diff adds or changes, marks it Covered, Not covered or Unknown against your tests, and ranks the tests worth adding. Copy it, paste your diff and tests.

Coverage reports tell you which lines ran. They do not tell you whether a test would fail if the change were wrong. A line can run in a test that never checks its result.

A better question for a code change is: what does this change do, and which test would catch it if it broke? An assistant can work through that by reading the diff and the tests together. It will not replace your test run, and it should not pretend to.

What you need

  • The diff: git diff main...HEAD, using your own base branch.
  • The test files closest to the code that changed. The prompt can only find coverage in what you paste.
  • The name of your test framework, if it is not obvious from the files.

The prompt

Paste this into a new chat, then paste the diff and the tests under it.

You find the test gaps in a code change. Work only from the diff and test files I paste below. You are not a coverage tool: never state a percentage and never say a test passes.

1. State in one line what the change does, as you understand it.
2. Go hunk by hunk and list each behaviour the change adds or alters in one plain sentence: new or changed branches, error paths, boundaries (empty, zero, one, maximum, off by one), new parameters and defaults, removed guards, changed return values or side effects, changed public interfaces.
3. For each behaviour search the tests I pasted for a test that would fail if the behaviour were wrong. Mark it Covered (name the test), Not covered (say what you searched) or Unknown (the test that would cover it was not pasted, or a test calls the code without asserting on this behaviour).
4. For each Not covered or Unknown behaviour that matters, propose one test: name, setup, input, expected result with the diff line you took it from, and why it matters. Rank by risk: data loss, security, money and public interfaces first. If the framework is clear, give a skeleton for the top three. If the code does not say what should happen, say so and ask.
5. Finish with what you could not see.
Do not edit anything.

Here are my diff and tests:

[paste the diff, then the test files]

How to check the result

Start with the list of behaviours. Is it a fair description of what you changed? If it missed one, tell the assistant and ask it to re-run that part. If it invented one, your diff was probably too large for one go. Split it.

Then take each Covered. The prompt asks for the test name. Open that test and check that it would really fail if the behaviour were wrong. A test that calls the function without asserting on the result is the usual trap.

For each Not covered, read the proposed test. The prompt asks for a setup, an input, an expected result and the diff line the expectation came from. If the expected result is not something your code actually promises, discard the test. The prompt is told to ask you when the code does not say what should happen, so answer it.

Write the top two or three tests first. The list is ranked by risk: data loss, security, money and public interfaces come before the rest.

Limits

  • It never runs your tests. It does not say a test passes and it never gives a coverage percentage.
  • Unknown is common. If the test that would cover a behaviour lives in a file you did not paste, you will see Unknown, not Not covered.
  • Large diffs give shallow answers. Review a pull request in slices.
  • It does not know your team's standards for what is worth testing. Treat the ranking as a starting order.

Browse all skills in the catalog

Want this as a ready-made skill? Test Gap Finder (Free) does it in your own assistant.