Metadata

Highlights

  • test-induced damage through using mocks to drive architecture, and how the red/green/refactor cycle of TDD never worked for him.
  • He thinks people have different brains and thus like different techniques and languages, he doesn’t like that TDD gets conflated with the confidence you get from self-testing code.
  • But in the non-TDD part he still used regression tests and short feedback loops. He has no problem mixing both styles, it’s like playing both classical and jazz.
  • what are you willing to sacrifice to get that flow? Many people make bad trade-offs, especially with heavy mocking.
  • But in response to David’s question about mocks, he said he rarely uses them, he’s concerned that those that do often find refactoring difficult, while he finds testing makes refactoring easier.
  • first that DHH’s critique of TDD was based on an assumption that you had to use heavy mocking in TDD, which isn’t the case;
  • test-induced design damage due to the complexity of excessive indirection. Kent thinks it’s less about TDD and more about the quality of design decisions.
  • Kent said that ascribing test-induced damage to TDD was like driving a car to a bad place and blaming the car for it.
  • Kent countered that it was rather one design decision at a time. TDD puts an evolutionary pressure on a design, people have different preferences for the grain-size of how much is covered by their tests.
  • He thinks the idea that someone wants to turn a rails application into a command-line application is so rare it’s laughable, similarly you can’t just swap out an in-memory store for a call to a web service because they have different operational characteristics.
  • David agreed that testing can lead to better designs, but said his experience often was also the opposite, that there wasn’t a good testable design.
  • Kent accused David of not having enough self-confidence, maybe you can’t see the insight today, so you have to make progress in the meantime, but he’s optimistic that he will find them eventually. David dismissed this as “faith-based TDD”
  • He thinks TDD got programmers to where “they got so over-confident that they felt they didn’t need QA”.
  • “I don’t think you can work on anything of material quality and produce great software without having somebody who’s not you test it.”
  • High reliability is important for space shuttles and pacemakers, but wrong for an exploratory web site. The rule of not writing a line of production code without a test doesn’t fit in with trade-offs around criticality.
  • some have taken programmer testing too far and don’t see the value of exploratory testing.
  • David says that worst of all is when developers are not part of of customer service.
  • Kent has said ‘you aren’t paid to write tests, you just write enough to be confident’
  • he doesn’t think you always get over-testing when you use TDD.
  • He said he’d often write a system-y test, write some code to implement it, refactor a bit, and end up throwing away the initial test. Many people freak out at throwing away tests, but you should if they don’t buy you anything.
    • Note: This is a great idea in the context of TDD: if unit testing is a tool while developing, maybe it doesn’t have to stay once I finished.
  • only test things that can possibly break.
  • “the sign of too much is whenever you change the code you think you expend more effort changing the tests than changing the code.”
  • the whole point is the double check where there is an error if they get a mismatch.
    • Note: Like double-entry bookkeeping in accounting.
  • he liked it and tried to apply it to everything but slowly realized that lots of areas in an MVC web application didn’t feel good for TDD.
  • But abandoning TDD doesn’t mean he wants to give up self-testing code - that’s always been the value of TDD to him.
  • this is exactly how someone should take on TDD (or any technique). Try it out, overuse it, settle into a mode that works for you.
  • “most people can’t leave good ideas the fuck alone.”
  • It’s always hard to tell if something bad happens due to something inherent in a technique or due to misuse of a technique. All we can do is keep repeating the basics and the good lessons.