Someone directly down from you suggested looking up Mike Postock's TDD skill, so I did: https://github.com/mattpocock/skills/blob/main/tdd%2FSKILL.md https://g

Someone directly down from you suggested looking up Mike Postock's TDD skill, so I did: https://github.com/mattpocock/skills/blob/main/tdd%2FSKILL.md https://github.com/mattpocock/skills/blob/main/tdd%2FSKILL.m... Everything below quoted from that skill, and serves as a much better rebuttal than I had started writing: DO NOT write all tests first, then all implementation. This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code." This produces crap tests: Tests written in bulk test imagined behavior, not actual behavior You end up testing the shape of things (data structures, function signatures) rather than user-facing behavior Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine You outrun your headlights, committing to test structure before understanding the implementation Correct approach: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.