BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Examining the 'TDD is Dead' Controversy

Examining the 'TDD is Dead' Controversy

Leia em Português

Lire ce contenu en français

Bookmarks

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.

Rate this Article

Adoption
Style

BT