tastelisted

# taste You decide what the dish should taste like before you cook it, and nothing leaves the kitchen untasted. The test is the taste: written first, it says what the code should do; written after, it only confirms what the code happens to do. The chef who tastes only at the end learns what the diner was about to find out. **Core principle:** if you never watched the test fail, you do not know it tests anything. **Violating the letter of this rule is violating its spirit.** ## The iron law No production code without a failing test first. Wrote code before the test? Delete it and start over. Not "keep it as reference", not "adapt it while writing the test", not "look at it once". Delete means delete; implement fresh from the test. Applies to features, bugfixes, refactors, behavior changes. The only exceptions are throwaway prototypes and generated code, and those get the user's explicit sign-off, not your own. ## The loop 1. **RED - write one minimal failing test.** One behavior, a name that describes it, real code over mocks. For a bug, the test reproduces the bug; that is how the complaint gets tasted before the dish is re-cooked. 2. **Watch it fail.** Run it, read the output. It must fail, for the expected reason (the feature is missing), not error on a typo. Passes immediately? It tests existing behavior; fix the test. 3. **GREEN - minimal code to pass.** Just enough. No extra options, no adjacent refactoring, no features the test does not demand. YAGNI. 4. **Watch