2014 Test-Driven Development (TDD) Survey Results

Scott W. Ambler + Associates
Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map
How to Measure Anything This survey was performed during May 2014 and there was 274 respondents. The survey was announced on my Twitter feed, and several LinkedIn discussion forums (Disciplined Agile Delivery, Agile and Lean Software Development, Scrum Practitioners and Considerate Enterprise Architecture Group).

The Survey Results

The goal of this survey was to explore what teams that have adopted test driven development (TDD) are doing in practice in addition to TDD to explore requirements, to explore design, and to test their solutions.
TDD is an approach that combines test-first development (TFD) and refactoring. With TFD you write a single test and then just enough production code to fulfill that test. Refactoring is a strategy where you improve the quality of something (source code, your database schema, your user interface) by making small changes to it that do not change its semantics - in other words refactoring is a clean-up activity that makes something better but does not add or subtract functionality. Because you write a test before you write the code the test in effect does double duty in that it both specifies and validates that piece of code. A test-driven approach can be applied at both the requirements level and at the design level.

Some findings include:


Figure 1. Requirement practices in addition to ATDD/BDD.

Requirements practices


Figure 2. Design practices in addition to TDD.

Design practices


Figure 3. Testing strategies in addition to TDD.

Testing practices




Downloads

Survey questions

The Survey Questions

Survey Data File

Raw Data

Survey Presentation

Summary Presentation



What You May Do With This Information

You may use this data as you see fit, but may not sell it in whole or in part. You may publish summaries of the findings, but if you do so you must reference the survey accordingly (include the name and the URL to this page). Feel free to contact me with questions. Better yet, if you publish, please let me know so I can link to your work.


Discussion of the Results

  1. As I indicated earlier, you wouldn't be able to infer the adoption rate of TDD from this survey due to the title and my approach to targetting potential respondents.
  2. This survey suffers from the fundamental challenges faced by all surveys.

Links to Other Articles/Surveys

  1. My other surveys

Why Share This Much Information?

I'm sharing the results, and in particular the source data, of my surveys for several reasons:

  1. Other people can do a much better job of analysis than I can. If they publish online, I am more than happy to include links to their articles/papers.
  2. Once I've published my article, I really don't have any reason not to share the information.
  3. Too many traditionalists out there like to use the "where's the proof" question as an excuse not to adopt agile techniques. By providing some evidence that a wide range of organizations seem to be adopting these techniques maybe we can get them to rethink things a bit.
  4. I think that it's a good thing to do and I invite others to do the same.