Write the Test First, Then the Code
Write the Test First, Then the Code
superpowers core skill · test-driven-development
In one line: Don't let AI pile up features then add tests. Have it write the test, watch it fail, then write just enough code to pass.
Scenario: write a shipping-fee function
Shipping rules are full of edge cases: free over 99, a surcharge for remote regions (Xinjiang/Tibet), tiered pricing by weight, free during promos. This kind of "many rules, tricky edges" function easily becomes code that "looks right but draws complaints about wrong shipping the day it ships." Prime TDD territory.
How to ask the AI
Use TDD for the shipping-fee function: for each rule write a failing test first (free over 99 / remote surcharge / weight tiers / promo free),
run it and show me it fails, then write the minimal code to pass. No implementation without a failing test first.
| ❌ Weak | ✅ Strong |
|---|---|
| Write the function, remember to test it | Test first, then implement — show me it go red |
| Handle all the cases | One rule, one test; minimal code to pass |
| Tests pass, good enough | Edge values like remote regions / the free-shipping threshold all need cases |
Catch one action: make it paste the "test fails" output. A test that never failed may not cover that shipping rule at all.
How it'll walk you through it
It loops one rule at a time: write the "free over 99" failing test -> run to confirm it really fails (not implemented yet) -> minimal code to pass -> run to confirm -> next, "remote surcharge," another loop... Each edge (98 vs 99 yuan, Xinjiang vs Shanghai) becomes a test. If you make it write the function first and add tests after, the rule says delete and start over.
Remember one line
test-driven-development = have the AI write the test and watch it fail, then implement. For edge-heavy logic like shipping, one rule one test up front — so production doesn't slap you with "wrong charge."