I’m a little bit late to the party, but I’ve been watching the debates around “Is TDD Dead?”. There are already many notes out there, but I still ended up taking my own, so here they are.

Part 1

Liberal (non-verbatim) citation from memory:

If an idea is obviously bad, find a cheap way to try it out. If it turns out to be not bad, then you’ve found something interesting. Ideas that are obviously good aren’t that interesting, because others would have tried them already.

  • Do you deserve to be confident as a programmer?
  • Ruby’s idea of programming happiness
  • Are certain personality types better suited to TDD?
  • Are certain kinds of problems better suited to TDD?
  • When TDD is not possible, aim for the shortest possible feedback loop
  • How much should you sacrifice to achieve TDD? Are mocks an acceptable cost?
  • Tests should couple to the interface, not the implementation
  • How much should you isolate your units?
  • People sometimes conflate TDD and self-testing code - they’re different and separate
  • TDD is just one way to get to self-testing code

Part 2

Design only matters when you go to change something. If it’s just sitting there, then it’s not a big deal.

  • Can TDD actually cause damage to design?
  • Hexagonal architecture and its misuse
  • Does TDD cause isolation?
  • Trade-off: level of decoupling vs effort
  • Cohesion and coupling: don’t always go together, sometimes even in opposition
  • Intermediate results can make your code more testable
  • Difficulty testing is a symptom of poor design
  • TDD can thus drive you towards better design

Continued here.