Argue on TDD

We do “TDD.” Oh really?

August 21st 2011 at 4:50 PM Posted to Agile,Development,Testing
During Agile 2011 I tried to speak to people about what technical practices they did, and to what degree as well. Unfortunately I left the conference slightly disappointed and now understand why Uncle Bob champions the Software Craftsmanship movement as a way of addressing a balance the agile community at large has lost.

Don’t get me wrong. I appreciate that we need to focus on people and system issues in software development just as well. However, it’s laughable to think that software development is the easy part. I’m not the only one who feels this way. In order to succeed at real agility, you need just as much discipline and attention to detail to the technical practices, tools and methods just as you do everything else. It seemed like people were trying to be a good sports team, by finding the best people, hiring the best coaches, and then forgetting to schedule time for the drills and training.

One particular conversation stuck with me. We had this in the airport lounge at Salt Lake City before departing for Chicago. It kind of went something like this:

Other: We only tend to TDD the happy path
Me: Oh? Out of interest, what sort of test coverage do you end up with?
Other: About 20 or 30%. Why, how about you?
Me: Depends on what sort of application. Adding up the different types of tests (unit, integration, acceptance), I’d probably guess in the high 80s to 90s.
Other: Wow. That’s really high.

This conversation got me thinking about whether the other person’s team really benefits from doing TDD. I’m guessing not. They are probably getting some value from the tests, but probably equal value by doing test after. If you really wanted to be a pedant, you could argue, how do you do TDD without actually driving (most of) the code with tests? I’m not a TDD zealot. I’ve even blogged about when to skip TDD, however one of the biggest benefits of writing tests is the feedback they give and the way that it changes the way that you design code. I’m guessing by skipping the “unhappy paths”, there’s plenty of feedback they miss out on.

----From Patrick Kua (ThoughtWorks)


Comment:
At the first, the unit test shouldn’t cover only 20%-30%, it’s not TDD and maybe the unit test code just to satisfied supervisor or somebody else, if we do it like that, the unit test has lost the original meaning and to be frank, it’s just a overloaded methodology in this situation.
There’re two many metrics in TDD, actually i’m interested in TDD and i’m a zealot on process or skill which will make the team to be successful, not just the “Successful delivery” only. TDD is the way to try to extract the marketable value, because it will be come true from the customer perspective. It will push the communication with stakeholder and make some important and massive business defect in the beginning phase.
We should consider about some cost-value rate, balance the resource ,short-term advantage and long-term advantage.
Perhaps I’m interested in Automate testing as well, but we should be sober on any disciplines and methodologies, we can do all thing which will push our team and project to be better. We will adopt all techs if it's necessary, includes the TDD and Automate.

-----From Phoebus