D.S

langrsoft.com

Langr Software Solutions » Is TDD Faster than TAD?

Langr Software Solutions » Is TDD Faster than TAD? — Main Menu — Home Consulting / Coaching Training - Information About Training - Student Quotes - Technical Training - Process Training Resources - Agile in a Flash blog - Articles - Jeff’s Wiselike Page (Q&A!) - Books Jeff’s Blog About Home Consulting / Coaching Training Information About Training Student Quotes Technical Training Process Training Resources Agile in a Flash blog Articles Jeff’s Wiselike Page (Q&A!) Books Jeff’s Blog About Is TDD Faster than TAD? February 24, 2011 By jlangr 9 Comments I do TDD mostly to support the ability to keep my code and design clean, with high confidence that I’m not breaking something in the process. Most developers who do not practice TDD refactor inadequately, because of the fear based on the very real likelihood of breaking the software. I can’t blame ’em for the fear. I’ve helped developers in environments where defects related to downtime had the potential to cost the company millions of dollars per minute. “Inadequate? How dare you!” Yes, inadequate. The best TADers (test-after developers) claim around 70%-75% coverage. The problem is that there’s usually some good, chewy, gristly meat in that 25% to 30% that isn’t covered, and is thus not easily or safely maintained. Costs go up. The system degrades in quality by definition. In contrast, I have very high confidence that I can move code about when doing TDD. I can also improve the structure and expressiveness of a system, making it far easier to maintain. Duplication is sooo easy to introduce in a system. It’s harder to spot, and even harder to fix if you don’t have fast tests providing high levels of coverage. I’ve seen one real case where introducing close-to-comprehensive unit tests on a system resulted in shrinkage down to about 1/3 its original size over a reasonably short period of time. And with most systems I’ve encountered, I can scan through the source code and quickly spot rampant bits of unnecessary duplication. Good code structure and expressiveness is also lacking in most systems. If you’ve been a developer for more than a few weeks, it’s almost a certainty that you’ve spent way too much time slogging through a multi-hundred or multi-thousand line long function, trying to understand how it works and how to fix it without breaking something else. In a well-structured (cohesive) system, the time to pinpoint and fix things can be reduced by almost an order of magnitude. TADers simply don’t eliminate duplication and clean up the code to this extent. It’s not a goal of TAD. Which would you rather maintain? The TAD system, or a system that’s half the size and double the expressiveness? There are many other reasons TDD allows me to go faster than TAD. The converse of my “ why TAD sucks ” reasons should hint at many of them. About the Author Social Share 9 Comments Shmoo July 14, 2011 at 2:01 am Reply Hi, Jeff, Thanks for another interesting article. You seldom fail to deliver. I realise that it was written a while ago but I hope you don’t mind some comments. “I do TDD mostly to support the ability to keep my code and design clean, with high confidence that I’m not breaking something in the process.” Well, your reasons for doing TDD are your own, but most view TDD as a design process; what gives you confidence that you’re not breaking something is not TDD but the unit tests that TDD provides, which TAD also provides, so you’re not making a distinction here between TDD and TAD (as your title might suggest). “Most developers who do not practice TDD refactor inadequately, because of the fear based on the very real likelihood of breaking the software.” Could you quote your source for this statement? Or is it from your own, anecdotal experience? It is an odd statement simply because, by definition, refactoring does not entail a very real likelihood of breaking software. Here’s what that chap Fowler says: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour. Its heart is a series of small behaviour preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Of course, Fowler can’t say define, “Small,” but I think most would agree that any refactoring that entailed a very real likelihood of breaking software is too big. This point stands independent of the process used, so it’s odd that you think that there is a correlation between misunderstanding refactoring and the set of developers who don’t practice TDD. ““Inadequate? How dare you!” Yes, inadequate. The best TADers (test-after developers) claim around 70%-75% coverage.” Forgive me if I’ve misunderstood, but you seem here to attempt to justify your claim that TADers don’t refactor adequately by pointing to their low (test) coverage. Refactoring, however, has nothing to do with coverage percentages. You seem t