Lesson 2 of 6
Building a test set
8 min read
You have a hunch your prompt is good. How do you turn a hunch into something you can prove — and re-prove after every change?
Inputs plus expectations
A test set is just a list of cases: a real input plus what a good answer should do. Pull the inputs from actual usage — support tickets, search queries, the weird stuff users type — and write down the expected behavior for each. That's the whole trick.
Each case is an input paired with an expectation. Run them all and you get a pass/fail per case plus one aggregate score.
Cover the failures, not just the happy path
The cases that earn their keep are the ugly ones: an empty message, a prompt-injection attempt, an angry customer, a tricky edge you saw break once. A test set full of easy wins scores high and teaches you nothing. Aim it at where the system is likely to fail.
Your test set is only as honest as its hardest cases. Mine failures from production and add each one as a new case.
Keep the set in version control next to the prompt. When a case flips from pass to fail, git tells you exactly which change did it.
The shape of it
- —A case = a real input plus the behavior a good answer should show.
- —Running the set gives you pass/fail per case and one score to track.
- —Weight it toward hard, ugly, failure-prone inputs — not happy-path wins.
- —Grow the set from real production failures over time.
Your test set is 20 easy questions and it scores 100%. Why should that make you suspicious?
Continue in the app
Take the whole Evals & Reliability course — tracked
Get your personalized path, progress and streaks in the app — this lesson and every next one, in order.