Can We Still Afford to Reject Test-Driven Development?

Test-Driven Development (TDD) is a practice that aims to increase both software quality and developer productivity. In a recent study, researchers found that many novice developers reject the adoption of TDD due to a lack of pleasure in certain development phases. Should this even be their decision to make?

Novice Developers Can Be Uncomfortable With TDD

In a study by Romano et al. from 2019, researchers investigated how the practice of test-driven development (TDD) affects the mood of novice software developers. They found evidence that developers liked TDD less than “their way” of development and specifically reported that TDD practitioners were less happy during the testing phase of development.

I find one of the most interesting parts of the study to be the following sentence:

“Conversely, developers following the non-TDD approach can decide when and what to test without (mindlessly) following a process. Such freedom of action — e.g., testing what is worth according to the developer’s own understanding — can explain the higher pleasure score of non-TDD developers.” — Romano et al., 2019

In other words, developers are interested in testing only those things that “seem important enough”. Following this argument, an average developer would reject the idea of TDD in favour of “traditional” development models mainly because TDD is less pleasurable. While they only investigated a group of 29 final-year undergraduate students and all the data was based on self-assessment, it seems consistent with statements I’ve read on various discussion forums.

However, there is considerable evidence that practicing TDD leads to a higher quality code and probably also to increased long-term productivity (although the latter point varies from industry to industry).

This leads me to the following question: if the average developer chooses to sacrifice long-term quality and productivity for short-term pleasure, how can the adoption rate of TDD still be increased?

The Adoption of TDD is Still Controversial

“TDD is important. TDD works. TDD is a professional discipline that all programmers should learn and practice. But it is not TDD that causes good or bad designs. You do that.” — Robert C. Martin (Uncle Bob)

On the one hand, there is a large group of experts (such as the famous author Robert C. Martin) who advocate TDD as a fundamental improvement to the discipline of software engineering. Just as a surgeon would sterilise their equipment before a medical procedure because it is just the way one works responsibly in the field of medicine, a software developer would use TDD.

On the other hand, many decision makers in companies that practice software engineering are still uninterested to adopt TDD. Their arguments include:

• Increased development time up-front
• Insufficient TDD experience
• Legacy code
• Lack of design
• Insufficient testing skills

However, the core problem from my perspective is that TDD is still viewed as a concept that is experimental or unproven. You don’t have to be Spotify, Netflix or Amazon to realise that TDD is here to stay and much like object-orientation or agile development will likely become mainstream.

In the end, the question is: should it really be the individual developer who makes the decision to adopt a technique which evidently increases the quality of software, especially in critical business applications where errors could cause real damage? Would we still allow a surgeon to reject sterilisation protocols?