This video’s explanation of where we’re at in our path of learning TDD changed my life. Don’t have to watch entire video, just 44:40 onwards.
Last week Twitter & LinkedIn algorithms showed me the same quote from 4 different people: “TDD is not about testing, it’s about Design!”. Tone of the posts were the same. I had bad sleep for 3 days in a row & was tired of this passive aggressive nonsense. Also felt sorry for them not realizing their tone will turn off the very people they’re trying to teach.
Tweeted “If TDD is not about testing, but instead about design, then please take ‘Test’ out of the name. Come on y’all. I know you’re frustrated w/lack of adoption, but the tests are in the name and in the way you do it.” Didn’t go over well & some healthy debate followed.
One guy linked me to the end part of this video explaining EXACTLY WHY these people are saying that. J. B. Rainsberger noticed there are “3 stages of TDD”. Stage 2 is when they learn bugs aren’t the bottleneck anymore, design is, specifically when cost of features goes up over time. The worry is when you ignore design long enough, you eventually hit the cost of continuing is more than the cost of starting over.
He calls ’em:
- Test First Programming
- Test Driven Design
- Patterns
Stage 1 reduces time it takes to see your mistakes. Pro is they become less costly b/c you see & fix them sooner.
Stage 2 the tests drive our design decisions. Hard to test? Bad design. Easy to test? Good design.
The interplay between 1 & 2 is neat. Despite authors dying to tell you about stage 2, people will ignore you when they’re drowning in technical debt. The theory is, at least in stage 1, they’re fixing mistakes and _causing_ design issues. However, those failings and learnings give them great things to practice when they reach stage 2.
Stage 3 (for now) is more about recognizing refactoring patterns that work in certain situations.
Stage 1 & 2 are about “learning a language”. Stage 1, speaking so people understand you. Stage 2 the difference between poetry and prose, style, register, etc.
Stage 3 is about linguistics; interested in patterns how tests driven design, how certain problems in tests signal certain problems in code, & how certain refactorings go together in a particular sequence often. If I’m _this_ situation, that refactoring will help, otherwise if I’m in _another_ situation, that _other_ refactoring will help, else trying this secondary refactoring.
Which refactorings can I use in Elm/ReScript safely that _cannot_ be used JavaScript/Python. You recognize the reason you have to write certain tests in Object Oriented programming b/c u don’t have clearly defined library functions w/composition like you do in Functional Programming. Why I test more & different things in TypeScript that I don’t bother doing in Elm.
Instead of a skill tree to level up, it’s more about where are you and what is my focus.
Top comments (0)