Is TDD Dead
This was a 1/2 hour discussion on Hangout that included:
- DHH
- Kent Beck
- Martin Fowler
The video can be seen here.
The 3 participants are in more agreement than disagreement:
- Automated regression testing is very important.
- For algorithmic well-bounded challenges, TDD is very effective.
- May not be as effective for less-understood challenges.
- Sometimes TDD helps
- Other times it obscures because new information upsets the developing test structure.
- This aspect is what gives DHH heartburn; doesn't want to be constrained to TDD when it isn't working for him.
- Takes skill to determine whether TDD is appropriate choice for you in any programming situation.
- A lot of what you do is personal preference. TDD is one of many paths to programming "comfort". When it works for you, use it; otherwise don't.
Thinks that there are too many rigidities in TDD discussion; too many people are arguing for
- Test speed is supreme.
- Isolated unit testing (i.e. lots of mocks) emphasis primary in design.
- red/green/refactor mandated
He doesn't agree w/ above. Certain cases are good for red/green; other cases he hasn't found useful.
In order to understanding something he wants to understand how it came about. TDD helps him to frame where it's coming from.
As a child encountered a primitive TDD.
As a trial, he tried TDD "formally" and it worked really well for him.
He has a lot of anxiety on big problems; testing expresses a "chunk" of information that he can then process.
At Chrysler was not TDD, but was test complete. I.e. tests came after coding.
As a programmer, do you have the "right" to feel confident?
Generally, the industry has not supported this. Beck thinks this is important.
Agrees that tests are necessary but TDD generally doesn't work for him. May be a personal style.
red/green/refactor isn't satisfactory for him.
Acknowledges that that is a good experience for others and that it works for others.
He has a hard time writing a test for it if he can't visualize it.
"TDD is one path to having comfort. It isn't the only path."
On a problem he was solving, he could TDD for the data structure. When he had to feed live data, he couldn't write a test. Essentially he was spiking. And so he hacked at it until he understood what he was working with.
Summary: TDD when the problem is clearly understood. When problem is not clearly understood, tried to reduce feedback loop to get it done other ways:
- logging
- identify unknown boundaries
Works from specific to general.
Related to Beck that TDD worked really well when the work was "pure".
When the work is unclear, what am I "going to have to give up" to get the work clear?
When the flow is natural, algorithmic, TDD is great.
But when the flow is not natural, not useful to force TDD because it prematurely ossifies the design.
Making a design testable comes w/ costs and benefits. Determining the tradeoffs is a skill. Used example of a compiler:
- End-to-end testing?
- Test it piece by piece?
Is a discoverable process.
If you don't have a good idea for a design, then TDD is a struggle. Sometimes the feedback loop trying sheds light.
Beck doesn't mock very much; implies it's a smell.
Tests returning nested mocks is a smell of bad design. (my comment: violation of Law of Demeter)
DHH damage implies extremely isolated unit testing. That is not necessarily a TDD requirement.
Need self-testing code. One command running the entire test suite is important; Fowler is willing get on "his high horse" and recommend it. TDD is one path to self-testing code.
He also doesn't mock much either.
Misses when the problem he's trying to solve doesn't lend itself to TDD, but that's real life occasionally. Frequently will lead to chunks that are TDD-able.
Principle he wants to trumpet is: self-testing code is more important than TDD; not vice-versa.
Ranting against what he thinks everyone defines TDD to be. (Yeah, stop it, we get it)
More important to him: having a design that fits his programming style. For him, tying unit tests to ActiveRecord is a positive, not a negative.
Wants to close the hangout. Proposed a new hangout in which we explore when and how TDD damages design.
Public Wiki by hedgeyedev is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
