Stage 5 · Lesson 5 of 6
Listing edge cases up front
Models write the well and the edges badly. Before you prompt, list the inputs most likely to break the code: empty, a single item, very large, zero, negative, null or missing, duplicates, unusual characters, time zones and daylight saving, concurrent calls, and a user without permission.
Not every item applies every time; pick the ones that do. Put them in the spec as tests or as "done when" cases, or ask the tool for its own list and add what it missed. Business rules deserve special care, because the model cannot know them: what happens to a discount on a refunded order is your decision, not its guess.
Common trapletting the tool decide which edge cases matter for rules only you and your users understand.
A question to check yourself, an AI practice session and 1 cheat sheet entry come when you add the roadmap to your account. Add it
Resources for this stage
Start with· follow one of these
- BookFreeTest-Driven Development with Python (Obey the Testing Goat)
Harry Percival · Intermediate
Free online: test-driven development taught step by step on a real web app
- BookPaidTest Driven Development: By Example
Kent Beck (Addison-Wesley) · Intermediate · Paid
Kent Beck's short classic on the red, green, refactor loop, worked through by example