Jim Coplien and Bob Martin Debate TDD
alexsmail1 HN recommenders · 2014–2017
163K views · interview · evergreen · Uploaded 2012-10-24
Jim Coplien and Bob Martin debate test-driven development and unit testing in an InfoQ video that grew out of a JAOO 2007 dispute. They also touch on design and architecture.
HN points to it as a fun, substantive exchange between two experienced practitioners on TDD's value.
38:47RailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
40:20"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson
Strange Loop Conference
1:03:55🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
54:20Bret Victor - Inventing on Principle
Rui Oliveira
32:56Bret Victor The Future of Programming
Joey Reid
1:02:26Solving Problems the Clojure Way - Rafal Dittwald
Clojure/north
52:35Debugging Under Fire: Keep your Head when Systems have Lost their Mind • Bryan Cantrill • GOTO 2017
GOTO Conferences
42:15"Performance Matters" by Emery Berger
Strange Loop Conference
3 comments from Hacker News
James Coplien and Bob Martin have a debate of TDD and unit testing. There is a video of it on YouTube: [VIDEO]
Yeah, I agree. TDD is also, you cannot write a single line of code without writing a failing unit test though. Well, I'm not a fan of that either. I mean, sometimes I like writing an acceptance test to begin with and work inwards. People sometimes interchangeably use "TDD" for "testing". Also, just because you do TDD, doesn't mean your code can be great, I've seen people assert pointless things and the unit has gotten so small that people now define them as methods in classes. Which I also think can lead to some crazy maintenance suite of tests. If you're interested, this was a fun discussion about TDD between two professionals: [VIDEO] Jim Coplien and Uncle Bob.
I feel James Coplien's advice on the question is interesting: [VIDEO] TLDW: "refactoring your way out" from a simple but too short-sighted design might take a ridiculous amount of work, compared what would have been necessary if you knew what a "correct" design for this problem was.