Most prompts are written against one example and then used on hundreds. The gap between those two situations is where the failures live, and testing for it is a repeatable process rather than a matter of care.
Write the prompt against the hardest example, not the easiest
The natural instinct is to develop against a clean, representative input, because that is the one you have in front of you. A prompt tuned that way encodes assumptions you never stated, because the example satisfied them silently.
Choosing an awkward example instead forces those assumptions into the text. If the prompt handles a messy input, the clean one is usually covered by the same instructions.
This costs more at the start and saves the round of surprises that otherwise arrives after the prompt is already in use across a team.
Build a small set of inputs that break in different ways
Five or six inputs are enough if they fail differently. Useful categories are the empty case, the oversized case, the case with the wrong format, and the case that is technically valid but semantically strange.
For a summarization prompt in an American office setting, that might be a one-line email, a forwarded thread with six replies, a message that is mostly a calendar invitation, and a message written in fragments.
Keep the set in a file rather than in your head. A test set that has to be reconstructed each time will not be run each time.
Run the whole set after every change
Prompt edits are not local. Adding a sentence to fix one behavior routinely changes how the model treats an unrelated instruction, because the model reads the whole prompt as one context.
Rerunning only the case you were fixing therefore tells you very little. The regression will appear in one of the cases you did not check, and it will appear in production.
Running six inputs takes a couple of minutes and is the single practice that separates prompts that stay working from prompts that quietly degrade.
Judge against a written expectation, not against your impression
Reading an output and deciding it looks fine is unreliable, because fluent text reads as correct. Before running the set, write down what a correct answer must contain for each input.
That expectation can be simple: names must be preserved exactly, the date must appear, no recommendation may be added. Then checking becomes a comparison rather than a judgment call.
Written criteria also make the test transferable, so a colleague can run it and reach the same verdict you would.
Record the failures you decided to accept
Some edge cases are not worth handling. A prompt that mishandles inputs your workflow will never produce is fine, provided that decision was made rather than overlooked.
Noting the accepted failures in a comment beside the prompt prevents the next person from spending an afternoon rediscovering them.
It also makes the boundary explicit, so when the input distribution changes, someone can see immediately which assumption stopped holding.