BT

Examining the 'TDD is Dead' Controversy

by Shane Hastie on Jun 04, 2014 |

Test Driven Development (TDD) is one of the core practices of eXtreme Programming (XP) (although the ideas predate XP by decades) and is considered by many to be one of the keys to agile software development delivering higher quality software. 

Recently DHH (David Heinemeier Hansson), Ruby on Rails author and founder of Basecamp gave the opening keynote at Railsconf 2014 (video available here) in which he challenged the value of TDD as it is often implemented.

He went on to write two posts expanding on the theme: “TDD is Dead – Long Live Testing” and “Test-induced design damage

Brian Oken summarised the points DHH made across the talk and posts as:

• Lots of developers that push TDD make you feel like your code is dirty if you are not using TDD.
• Driving your design from unit tests is not a good idea.
• The TDD notion of “tests must be fast” is shortsighted.
• The faith in TDD can lead to completely forgetting about system testing.
• The focus on the unit and the unit only doesn’t help with producing a great system.
• 100% coverage is silly
• Programmers want software to be a science, but it isn’t. It’s more like creative writing.
• Good software isn’t like engineering.
• It’s like writing. Clear concise writing is better than convoluted writing.
• Clarity is good. So good that clarity should be the number one goal, not test coverage or test speed.
• Being a good developer is as hard as becoming a good writer.
• Just like writing, the way to become a good programmer is to write a lot of software, read a lot of software, aim for clarity.

The reaction in the community has been extensive (see the tweets with hashtag #tddisdead) with reactions ranging from “of course” to “that’s so stupid” (and every point on the spectrum between the two).

Much of the response has focused on the need to apply TDD pragmatically.

Uncle Bob Martin says in a response that  “If you aren't doing TDD, or something as effective as TDD, then you should feel bad.” He continues

Why do we do TDD? We do TDD for one overriding reason and several less important reasons. The less important reasons are:
1. We spend less time debugging.
2. The tests act as accurate, precise, and unambiguous documentation at the lowest level of the system.
3. Writing tests first requires decoupling that other testing strategies do not; and we believe 0 that such decoupling is beneficial.
Those are ancillary benefits of TDD; and they are debatable. There is, however, one benefit that, given certain conditions are met, cannot be debated:
• If you have a test suite that you trust so much that you are willing to deploy the system based solely on those tests passing; and if that test suite can be executed in seconds, or minutes, then you can quickly and easily clean the code without fear.

Martin Fowler hosted a series of recorded hangout conversations between DHH, Kent Beck (whose initial response can be found here) and himself to explore the use of TDD and its impact on software design.

So far there have been four hangouts, with the next scheduled for 4 June, which will be a Q&A session with questions from the public.

 He summarises the conversations so far as follows:

1) We talk about our varying experiences with the flow of TDD, and the way TDD and self-testing code are often confused.
2) David feels that using TDD leads to approaches such as hexagonal rails that is 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.
3) We discuss the various ways in which we get feedback while programming and the role of QA in providing feedback to developers.
4) We discuss some downsides of testing and TDD: can you do too much testing, and is there a problem with teams valuing tests more than they value the functional code?

Gergely Brautigam says in a post titled “TDD is Dead – Not really”  

TDD is NOT DEAD. Obviously since it has soooo many supporters how could it be dead? It’s like asking, is Design Patterns dead? Or is Functional Automation dead? Or is Oreo cookies dead?
No, it’s not dead. And it won’t ever be dead. It will maybe change into something new, something better even, but it will never be dead. So let’s skip that part.

He goes on to talk about the importance of testing at multiple levels and the common reasons testing is not done well in many software teams. He cites a lack of concern for quality as a common perspective and the time pressure many developers find themselves under as the most common reasons not to build tests as they write code.
He concludes:

It’s my personal opinion, experience and observation of a 10 year time period in Software Testing. Starting with at least a Weak Skeleton and a few upfront tests will help you in the long run. Writing at least ONE – TWO acceptance tests WILL help you understand business logic better. Writing ONE or TWO unit tests will help you understand your logic better. I’m not saying write a whole damn suite of tests I can understand you don’t want to do that, but for quality’s sake write at least a couple.

Gil Zilberfeld makes the point about following the advice from Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.
We’re not done uncovering yet. TDD is one item we found on our journey, there are others.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

DHH isn't thinking clearly by peter lin

Just because some people who are obsessed with decoupling gave him nightmares, blaming TDD just doesn't make sense. Testing should be practical. Developers are going to abuse languages, tools and methodologies no matter what. That would be like blaming rails because a few developers write junk.

Re: DHH isn't thinking clearly by Cameron Purdy

On the other hand, Kent blaming the quality of the designer / engineer is just as disingenuous. Of course brilliant designers and engineers will succeed with TDD, for the same reasons that brilliant designers and engineers will succeed without TDD. The logical fallacy is that TDD is the reason for the success, which it is not. (Just to be clear: brilliant designers and engineers will succeed with the Waterfall Methodology, and likely just as often as they succeed with TDD.) That said, it is apparent that a number of very good engineers prefer the development process with and/or the final results of TDD, so there is likely some value to it.

Peace,

Cameron Purdy | Oracle
... my own opinions, and not speaking for my employer.

--- Edit: note the duplicate post; somebody didn't implement idempotency

Re: DHH isn't thinking clearly by Cameron Purdy

On the other hand, Kent blaming the quality of the designer / engineer is just as disingenuous. Of course brilliant designers and engineers will succeed with TDD, for the same reasons that brilliant designers and engineers will succeed without TDD. The logical fallacy is that TDD is the reason for the success, which it is not. (Just to be clear: brilliant designers and engineers will succeed with the Waterfall Methodology, and likely just as often as they succeed with TDD.) That said, it is apparent that a number of very good engineers prefer the development process with and/or the final results of TDD, so there is likely some value to it.

Peace,

Cameron Purdy | Oracle
... my own opinions, and not speaking for my employer.

Re: DHH isn't thinking clearly by Mike Lythgoe

I've never felt comfortable with changing my design to help unit tests.
I'm happy to agree that unit tests have helped me make changes and feel confident I haven't broken anything (more so than if I didn't write unit tests) but when I start to change the design for the sole reason of making it easier to write unit tests, it feels like the tail is wagging the dog.

Literate Programming by Bart Blacha

Donald Knuth doesn't do TDD. For his toughest projects, he does Literate Programming. Which agrees with this article that programming is like creative writing (and, later, reading.)

Re: Literate Programming by Mileta Cekovic

Literate Programming maybe had made sense decades ago, with programming languages like C or assembler, but today when most modern languages are expressive and readable and in the era of fluent APIs, Literate Programming brings little or no value...

Re: DHH isn't thinking clearly by peter lin

On the other hand, Kent blaming the quality of the designer / engineer is just as disingenuous. Of course brilliant designers and engineers will succeed with TDD, for the same reasons that brilliant designers and engineers will succeed without TDD. The logical fallacy is that TDD is the reason for the success, which it is not. (Just to be clear: brilliant designers and engineers will succeed with the Waterfall Methodology, and likely just as often as they succeed with TDD.) That said, it is apparent that a number of very good engineers prefer the development process with and/or the final results of TDD, so there is likely some value to it.

Peace,

Cameron Purdy | Oracle
... my own opinions, and not speaking for my employer.

--- Edit: note the duplicate post; somebody didn't implement idempotency


Totally agree. TDD is just another tool to me. Good people make things work and get the job done properly.

Re: DHH isn't thinking clearly by Nick Watts

This can be a very good thing. I used to feel the same way, but after enough convincing from coworkers, I tried it their way (deliberately changing my architecture to allow more thorough uni testing). I discovered that when a class is difficult to unit test - that tells me there's *already* a problem with the architecture. Coupling is what makes classes hard to test. If it's hard to replace a dependency with a mock, that's a sign that my architecture is sub-par.

This is obviously in broad strokes, but it has definitely happened to me plenty of times now, where trying to write tests has shown me hard-coded dependencies I didn't realise I had, and ought to fix.

Type safety by Chris Melikian

From what I've seen, a lot of people are moaning about TDD because they are breaking tests when refactoring which leads to them having to run tests each time to see what needs to be refactored. This seems more to do with TDD and type safety rather than TDD per se. I doubt whether Java devs are so vocal about TDD being dead.

"TDD is dead" is an eye-catching headline, but irrelevant by Stephen F. Heffner

I have been doing what I call "moderate TDD" since long before TDD had a name. Extreme TDD is, like most extreme things, impractical and contrary to human nature; the idea that tests should (or even can) substitute for design is, IMHO, silly. (BTW, even moderation can be taken to extremes!)

I start creating tests during the requirements / "imagineering" phase of a project, to help me clarify what I'm thinking about and to elicit better requirements. (This is closely related to prototyping, another great idea.) I continue to refine / refactor those tests and add new ones through the design phase, where they continue to help me clarify my approach and the design itself. I then use them as unit tests during development, especially when I need to refactor. They then become part of my regression test bed. But their usefulness doesn't stop there; they also serve as training aids and, because of the nature of what I do, marketing aids as well.

The argument that maintaining tests is too onerous reminds me of similar arguments against commenting code. In my view, maintenance of tests and comments is just as important as maintenance as the code itself. When this principle is deeply enough instilled, it becomes second nature and, instead of costing time, saves it, through clarity of vision, design, execution, and QA -- i.e., throughout the SDLC.

Re: Type safety by Cliff Berg

Actually, I do development in both ruby and java, and with ruby I find that I need unit tests, but with java I don't. Java's type safety allows me to refactor with a much higher level of confidence.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT