Is TDD dead?
Thoughtworks1 HN recommender · recommended in 1 month, 2014–2022
talk · intermediate · evergreen · 2014–2022 on HN
A Thoughtworks conversation among Martin Fowler, Kent Beck and David Heinemeier Hansson on whether TDD is dead. They discuss the tradeoffs of test-driven development, mocking and where TDD helps or hurts design.
Recommended in TDD and unit-testing threads as a balanced debate among three prominent developers that avoids dogma.
Up next
15 mo on HNRailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
15 HN recommender · 2015–2025
11 mo on HN"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson
Strange Loop Conference
12 HN recommender · 2014–2024
11 mo on HN🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
11 HN recommender · 2018–2024
11 mo on HNBret Victor - Inventing on Principle
Rui Oliveira
12 HN recommender · 2013–2025
11 mo on HNSolving Problems the Clojure Way - Rafal Dittwald
Clojure/north
10 HN recommender · 2019–2025
11 mo on HNDebugging Under Fire: Keep your Head when Systems have Lost their Mind • Bryan Cantrill • GOTO 2017
GOTO Conferences
8 HN recommender · 2018–2025
10 mo on HN"Performance Matters" by Emery Berger
Strange Loop Conference
12 HN recommender · 2019–2025
10 mo on HNA Tour of the Acme Editor
Russ Cox
11 HN recommender · 2012–2026
8 mo on HNTech Talk: Linus Torvalds on git
Google
9 HN recommender · 2007–2023
9 mo on HN"How NOT to Measure Latency" by Gil Tene
Strange Loop Conference
9 HN recommender · 2015–2026
9 mo on HNRuby Conf 12 - Boundaries by Gary Bernhardt
Confreaks
8 HN recommender · 2015–2024
9 mo on HNUsing Python to Code by Voice
Next Day Video
12 HN recommender · 2013–2025
5 comments from Hacker News
I can't recommend the discussion between Kent Beck, David Hansson and Martin Fowler enough. They look at how and where it should be used and in particular discuss their approach to mocking which I feel is an often misunderstood tool. Part 1 - ▶ this video Part 2 - link Part 3 - link Part 4/5 - link
It says that "Nintendo" or "任天堂" the brand name refers to an old Chinese saying "謀事在人,成事在天" which means "Man proposes, God disposes", or "do your best and leave it to the fate". The idea is not far from the stoic ones - try your best and stop worrying. It's like an idea from this classic debate on TDD [0]: Unit tests make you confident. You write it, you forget it. It makes you sleep at night. In my first few years of my career, I was constantly and unconsciously thinking about the code, the business requirement, the team, even outside the working hours. That stressed and drained me a lot. In the end I realized I shouldn't have done that. If I am to worry about those things, I just book myself a calendar and go over those things within the time-box. If I need more time, I book another time block for the next day - as simple as that. Now write that "unit test", forget it, and sleep well at night. If you really need to worry about them, you should have a "quarterly/monthly worrying day" to reflect about your life, your career, strategies and all that. Outside that day, you just live your happy life. [0] ▶ this video
Hot take. Unit testing is not overrated, if you feel this way you likely just suck at optimising your suite for high RoI tests or chase some stupid metric like code coverage getting mad when you find out you wasted a bunch of time writing worthless tests. ▶ this video
I'm not sure I buy this. Quote from Martin Fowler: ▶ this video > I share with with David and Kent, there are problems where TDD doesn't work terribly well, and sadly most of the programming I do these days is not conducive to TDD and I miss it because actually I really like the TDD flow that really works for me just as it works the Kent.
> Because DHH is just one person. And he only has DHH's experiences. Yep. Uncle Bob is one person, too. tl;dr Think for yourself and don't listen to somebody just because they hurt your feelings. > To pick a topical example: Is TDD hard in Rails apps because TDD is dead or because Rails makes TDD hard? This is a misrepresentation of what DHH has said [1], which is that strict adherence to TDD can make your designs worse: > Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it started hurting my designs. > Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test. If you watch the conversations between DHH, Martin Fowler, and Kent Beck, it seems to me that they all agree: testing is good, test-driven design can be bad, and mocking everything is bad [2][3]. I took some time last week to re-read Uncle Bob's book, Agile Software Development, Principles, Patterns, and Practices [4], and Kent Beck's book on TDD [5]. There was a huge difference: Uncle Bob focuses on test-driven design , while Kent Beck focuses on test-driven development . Uncle Bob claims that test-driven development (especially through mocks) universally improves your design, because it reduces coupling and enables refactoring. Kent Beck t