Skip to content
PromptsBuddy
All prompts
EngineeringintermediateClaudeChatGPT

The test case you would have forgotten

Reads a function and enumerates the boundaries, empty states, and concurrency cases you didn't think of — then writes only the tests that could actually fail.

MeghnaMeghna · Staff engineerAug 26, 2026v1.0
The prompt· 0/3 variables filled
~290 tokens
Find the cases I have not thought about.

CODE:
{{CODE}}

STACK: {{STACK}}
TESTS THAT ALREADY EXIST: {{EXISTING}}

**1. Enumerate the input space.** For each parameter: the boundary values, the
empty or zero case, the maximum, the malformed case, and anything nullable.
Then the combinations that interact.

**2. Beyond inputs.** Ordering and concurrency, partial failure, repeated calls
(is this idempotent?), timezone and locale, and what happens if a dependency is
slow rather than down.

**3. Rank by "could this actually happen and would it hurt?"** Drop anything
that is theoretically possible but harmless — say you dropped it and why.

**4. Write the top tests** for {{STACK}}. Each test name states the behaviour,
not the method name. Include the assertion that would fail today if the bug
were present.

Rules:
- Do not write tests that restate the implementation. If a test would pass for
  any implementation of this signature, it is worthless — skip it.
- Do not duplicate what already exists.
- Do not mock the thing under test.
- If a case cannot be tested without changing the code's shape, say so and say
  what change would make it testable.

Tools for this prompt

Where the input below comes from. The ones marked needed change the output a lot — fallbacks for each are further down.

  • GitHubneeded MCPThe function under test and the tests that already exist, so it doesn't duplicate them.

Fill in the blanks

Run it in:ClaudeChatGPT

What goes in each blank

CODE
The function or module under test, plus its types.e.g. Paste the source.
STACK
Language and test framework, so the output is runnable.e.g. TypeScript, Vitest, no mocking library.
EXISTING
Tests that already exist, so it doesn't duplicate them. 'None' is fine.e.g. One happy-path test for the basic case.

Notes from people who use it

  • Section 1 is worth reading even if you write the tests yourself — the enumeration is the part humans skip.
  • The 'would fail today' requirement filters out tests that assert nothing.
  • Ask about idempotency explicitly for anything that touches money, email, or external APIs.

What to bring

This prompt is only as good as what you feed it. Web search covers anything public — these are the inputs it can't reach.

  • GitHubneeded MCP

    The function under test and the tests that already exist, so it doesn't duplicate them.

    Don't have it: Ask the user to paste the diff or file directly.

Only tools that web search cannot replace are listed. Anything public — reviews, job ads, papers, salary data — an agent can already fetch, so it is not listed here. No paid placements or affiliate links; if that changes, this line will say so.

Use this as a skill

A prompt is a skill with the serial numbers filed off. Install it once and your agent reaches for it on its own.

Paste this into ChatGPT, Claude Code, Codex, Cursor, or whatever you use:

Install the the-test-you-would-have-forgotten skill globally from https://promptsbuddy.com/prompts/the-test-you-would-have-forgotten/skill.md
Add to Cursor

.claude/skills/the-test-you-would-have-forgotten/SKILL.md

---
name: the-test-you-would-have-forgotten
description: "Reads a function and enumerates the boundaries, empty states, and concurrency cases you didn't think of — then writes only the tests that could actually fail. Use when the user asks for help with engineering tasks like testing, engineering, quality."
license: CC-BY-4.0
metadata:
  source: https://promptsbuddy.com/prompts/the-test-you-would-have-forgotten
  author: "Meghna"
  version: "1.0"
---

# The test case you would have forgotten

Reads a function and enumerates the boundaries, empty states, and concurrency cases you didn't think of — then writes only the tests that could actually fail.

## Inputs to collect first

Ask the user for anything below that they have not already given you. Do not
invent values for these.

- `CODE` — The function or module under test, plus its types. (e.g. Paste the source.)
- `STACK` — Language and test framework, so the output is runnable. (e.g. TypeScript, Vitest, no mocking library.)
- `EXISTING` — Tests that already exist, so it doesn't duplicate them. 'None' is fine. (e.g. One happy-path test for the basic case.)

## Tools this works with

Do not require any of these. If one is unavailable, use the stated fallback and
say which input is missing rather than inventing it.

- **GitHub** (needed) — The function under test and the tests that already exist, so it doesn't duplicate them. If its MCP server is connected, fetch this yourself.
  - Without it: Ask the user to paste the diff or file directly.
  - https://github.com/

## Instructions

Find the cases I have not thought about.

CODE:
{{CODE}}

STACK: {{STACK}}
TESTS THAT ALREADY EXIST: {{EXISTING}}

**1. Enumerate the input space.** For each parameter: the boundary values, the
empty or zero case, the maximum, the malformed case, and anything nullable.
Then the combinations that interact.

**2. Beyond inputs.** Ordering and concurrency, partial failure, repeated calls
(is this idempotent?), timezone and locale, and what happens if a dependency is
slow rather than down.

**3. Rank by "could this actually happen and would it hurt?"** Drop anything
that is theoretically possible but harmless — say you dropped it and why.

**4. Write the top tests** for {{STACK}}. Each test name states the behaviour,
not the method name. Include the assertion that would fail today if the bug
were present.

Rules:
- Do not write tests that restate the implementation. If a test would pass for
  any implementation of this signature, it is worthless — skip it.
- Do not duplicate what already exists.
- Do not mock the thing under test.
- If a case cannot be tested without changing the code's shape, say so and say
  what change would make it testable.

## Notes from people who use this

- Section 1 is worth reading even if you write the tests yourself — the enumeration is the part humans skip.
- The 'would fail today' requirement filters out tests that assert nothing.
- Ask about idempotency explicitly for anything that touches money, email, or external APIs.

---

The test case you would have forgotten · by Meghna · v1.0
From PromptsBuddy — https://promptsbuddy.com/prompts/the-test-you-would-have-forgotten
Licensed CC BY 4.0.

Every prompt is also available at /prompts/the-test-you-would-have-forgotten/skill.md — see all install options.

Enumeration is the boring part

Engineers skip boundary enumeration not because it is hard but because it is tedious, and tedium is exactly what to hand over. The model will list the empty array, the single-element array, the duplicate keys, and the timezone case without getting bored on case eleven.

Tests that could fail

The instruction that earns its place is "include the assertion that would fail today if the bug were present." Without it you get coverage-shaped tests that assert the code does what the code does, which is how suites end up green, enormous, and worthless.

Try these next

EngineeringintermediateStaff pick

A code review that teaches instead of nitpicks

Reviews a diff at three altitudes — design, correctness, style — and explains the reasoning behind each note so the author learns something instead of just applying a patch.

ClaudeChatGPT3 vars
MeghnaMeghna
EngineeringintermediateStaff pick

Debug from a stack trace without guessing

Forces the model to separate what the trace proves from what it's inferring, rank hypotheses by testability, and give you the cheapest experiment that discriminates between them.

ClaudeChatGPT3 vars
MeghnaMeghna