I started doing TDD in 1999. I decided to tweet twenty random thoughts on TDD, roughly one per business day starting 2019 February 14, using the hashtag #20YearsTDD. Each tweet represents a good topic for an article that I should write (and might already have written).
Here are the tweets from #20YearsTDD. They appear in the order posted:
-
70% coverage (a typical claim by test-after folks) sounds good until you realize that means almost a 3rd of your system is at risk and thus more rigid.
-
TDD is a simple and dumb cycle, in that it doesn’t bring the magic, you do: TDD allows you to continually think about and address design.
-
The hardest part of TDD: It’s a habit you must ingrain; harder still if you have a different habit you must break.
-
Doing test-after dev (TAD) should, in theory, be able to provide the same improved design results as TDD. In reality, I’ve never seen it happen. People don’t generally clean up their design because they wrote some tests after.
-
That ~70% coverage suggested as a good goal by test-after (TAD) proponents isn’t uniform. It’s more like 26% here, 63% there, 84% there. That means you’re always wasting time figuring out just what protections you truly have.
-
Were a manager to have long ago told me “you have to do TDD,” (like they tell people to write unit tests), I probably would’ve told ’em to get lost, then found ways to not do it. Mandates get you nowhere.
-
TDD forces the issue of breaking things down into small, incremental chunks–probably one of the most useful things you can learn as a developer. And you’ll get better at it quickly.
-
Devs always want to learn “how do I fix my legacy mess” first. But there’s not much point teaching how until they know what a good system looks like, and how TDD might help get them there.
-
TDD accommodates–and requires–continual thinking about design, at every step of red-green-refactor, every time. It’s all design.
-
“In a clean, well-designed system, I probably spend roughly the same amount of time reading code as I do writing it. In a poorly-designed system, I spend far more time reading code than writing it.” (“How much time do you spend writing code vs. reading code,” via Quora)
-
TDD won’t magically take you to Great DesignWorld; you have to know the route. In contrast, not doing TDD basically clamps you to railroad tracks to eventual Design Dismaland.
-
TDD is a great tool in your toolbox that helps shape code & eliminate logic defects (among other things). TDD alone is is insufficient enough to support all your developer testing needs.
-
TDD will help you document the thousands of little choices you made in your system… info that otherwise can take hours to learn when you later need to know the choices you made.
-
TDD does takes more time initially–when you first start learning; also when you first start a new effort. You can save time by not doing TDD for the first day or so. After that, you’re chewing up far more time than you think you saved.
-
Hypothesis: (In a test-after system) Code and complexity grow more rapidly in the uncovered areas of a system, making those areas increasingly more brittle and rigid.
-
There is no dichotomy: Doing TDD does not come at the expense of other forms of testing.
-
The TDD stumbling block for seasoned developers: “I know what the implementation needs to be in 30 minutes, why can’t I just code it now?”
-
A small secret: Almost everyone thinks writing unit tests after code (TAD) is tedious, not fun, and only moderately useful. Infected folks usually find TDD to be a lot of fun and extremely useful.
-
I continue to do TDD because it’s a lot of fun. Even though it’s also gratifying to be able to ship clean, working code, I wouldn’t do TDD if I hated it.
-
The habits & things I continue to embrace are those that either bring me “geek joy” or ensure security. TDD provides both. “Geek joy” is what it’s mostly about.
Comments
I would love to see an article on “Geek Joy”. I had some of that today. Found that some tools that we were interested in getting were approved and should make life that much more joyful. 🙂
🙂 Work should be happy.
It’s a great idea for an article. You should write one too.
