Writing the acceptance checks before the code

The gap between it works and it does what I meant

An agent finishes and reports success. What was verified? That the code compiles, usually, and sometimes that a test it wrote passes. Nothing checked that the feature does the thing in your head, because the thing in your head was never written down in a form that could fail.

An acceptance check is that form. It is one sentence with three parts, in ordinary words, written before the work.

Given a booking at 14:00 for Anita lasting 30 minutes,

when a customer tries to book Anita at 14:15,

then the booking is refused and the message names the next three free slots.

You can hand that to a model, a tester, or yourself in a month, and all three will check the same thing.

Why before

Written afterwards, a check describes what the code does. That is a description, not a test: it will pass by construction and tell you nothing.

Written first, it is a commitment. If the code does something else, one of you is wrong, and finding out which is the whole point.

This is the same discipline as writing down what result would make you ship before you run an experiment. The order is what makes it honest.

Five checks per feature, not fifty

More is not better. For each feature, write:

• One happy path. The thing working normally.
• One boundary. The edge of a rule. A booking that starts exactly when another ends. A cart of exactly zero items. A name of exactly 100 characters.
• One refusal. The thing that must not be allowed, and the message the person sees.
• One permission. Somebody else’s data, attempted by the wrong person. Every feature that touches user data gets this one.
• One recovery. What happens when the network drops mid-save, or the user presses back, or submits twice.

Those five catch the great majority of what actually goes wrong in generated code, and they take about ten minutes to write.

The double-submit check, specifically

Write this one down for every form that costs money or creates something:

Given a customer on the booking form, when they press Book twice quickly, then exactly one booking exists.

Generated forms fail this constantly. The button stays enabled, the request fires twice, and you have two identical bookings, two charges, or two emails. It is not an exotic edge case: impatient people on slow connections do it every day.

Turning checks into tests, later

Each of these can eventually become an automated test, and the good news is that the hard part is already done. A model given a written acceptance check writes a decent test from it, because the check already names the setup, the action and the expected result.

Do not automate them all on day one. Write them as sentences, check them by hand, and convert the ones you are tired of repeating. The testing lesson later in this course covers which five to automate first.

Hand them over with the request

Build the overlap rule. It must satisfy:

1. 14:00 booking, 30 min. New booking at 14:15 for the same
   stylist: refused.
2. 14:00 booking, 30 min. New booking at 14:30 for the same
   stylist: allowed. Back to back is fine.
3. 14:15 for a different stylist: allowed.
4. Refusal message lists the next three free slots that day.
5. Two identical requests sent at once create one booking.

After you finish, tell me how you verified each of the five.

That last sentence is worth including every time. It converts “done” into a claim about evidence, and a vague answer to it is itself informative: if the model cannot say how it verified check 5, then check 5 is not done.

The check that never passes

Sometimes you write a check and discover you cannot say what the right answer is. Two customers, same slot, requests one millisecond apart. Which one wins?

That is not a failure of the method. That is the method working: it found a decision nobody had made. Make it, write it down, and continue. Finding those before the code exists is most of what this practice buys you.