Test-Driven Development (TDD): 2014 Open Research
 |
This open research into test-driven development (TDD) adoption 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:
- As you can see in Figure 1, people who were practicing Acceptance Test Driven Development (ATDD)/Behavior Driven Development (BDD) were very often following other agile requirements practices.
- Figure 2, people practicing developer-level Test Driven Development (TDD) were commonly following other agile design practices.
- Figure 3, people practicing TDD were commonly working on teams that were also performing other agile testing strategies.
Figure 1. Requirement practices in addition to ATDD/BDD.
Figure 2. Design practices in addition to TDD.
Figure 3. Testing strategies in addition to TDD.
Downloads
|
|
|
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
- 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.
- This survey suffers from the fundamental challenges faced by all surveys.
Links to Other Articles/Surveys
Why Share This Much Information?
I’m sharing the results, and in particular the source data, of my surveys for several reasons:
- 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.
- Once I’ve published my article, I really don’t have any reason not to share the information.
- 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.
- I think that it’s a good thing to do and I invite others to do the same.