test-truth

Topics in the source

• Tests that prove something
• Sabotage is how you check a test
• Traps that keep a broken suite green
• One test account
• Review checklist

A green suite proves only that nothing it checks failed. Whether it checks the right thing is a separate question, and you answer it by breaking the code. After writing a test, break the code it protects (invert a condition, return early, delete the call) and run it. It must turn red. Put the code back and it must turn green. A test you never saw fail has not been tested. Two locks, one test. When two checks guard the same result (one on write, one on read), an end-to-end test passes while either one alone still holds. Give each check its own assertion that fails when only that check is gone, and sabotage them one at a time. A 200 on a write proves nothing. The old version also answers 200. Write a value that did not exist before this run (a timestamp, a random id) and look for that exact value when you read back. Retry the read a few times before failing: a cache serving the old version for seconds is the cache working. The API does not prove the screen. A blank page leaves every API green. A journey that matters drives the real interface (see the verify skill). Skipped means silent. skipIf(!exists(path)) turns into a no-op when the path moves, and nothing reports it. Fail when a

This is an excerpt. Refer to the complete source and its current requirements.