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.