ME:: tl;dr-ing: When we write the code to pass the test, it must be failing; Jason Gorman:: Test Driven Development Under The Microscope #1 – Usage-Driven Design
Discovered: Sep 24, 2025 08:45 (UTC)ME:: tl;dr-ing: When we write the code to pass the test, it must be failing; Jason Gorman:: Test Driven Development Under The Microscope #1 – Usage-Driven Design
QUOTE
- Read the whole thing: Jason Gorman:: TDD Under The Microscope #1 – Usage-Driven Design – Codemanship’s Blog
A more flexible and robust way to describe workflow is to imply ordering of events declaratively*. Instead of “Boil the kettle, then pour the water into the teapot”, we might say “When the water is poured into the teapot, it must be at near boiling”. Now all of our edge cases work. We could have boiled it in a pan. We could have boiled it in a microwave. We could have watched the squirrel and then boiled the kettle again. Workflow is implied: the water has been boiled, but we leave ourselves many more routes to pouring it in the teapot.
A similar approach can be taken with workflows like TDD; instead of “Run the test to see it fail, then write the simplest code to pass it”, we could say “When we write the code to pass the test, it must be failing”. It’s a subtle but important distinction, and one which I’ve realised I’ve been using for a long time when I observe developers working.