We fear what's different
Test-Driven Development (TDD) is a software development approach that involves writing tests for a piece of code before writing the code itself. The goal of TDD is “clean code that works”, meaning that the code should be working as expected but also with a good design. Something that is pretty important, especially since I strongly believe that there is no agility without technical excellence.
TDD follows a specific workflow, known as the TDD cycle of Red/Green/Refactor:
- RED → write a test that fails
- GREEN -> pass the test ASAP
- REFACTOR -> improve design keeping tests green
Test-Driven Development has several benefits, including improved quality and reliability of code, improved maintainability, and faster development - in general, is a technique that allows you to face any business problem you find yourself to face because it’s a strategy to explore problems.
However, even if there is a lot of evidence out there proofing the good of this practice, a lot of developers still resist it and are afraid of it. So I asked myself: how is that possible? Why do those brilliant people still resist a practice that brings such big advantages? There must be some reasons I can’t see. Here’s what I found.
There are several reasons I was able to collect about why a lot of developers are afraid of embracing Test-Driven Development:
- Lack of familiarity: developers that are unfamiliar with TDD (and maybe even with test automation) may feel overwhelmed by the idea of writing tests before writing code.
- Fear of change: TDD involves a different way of thinking about and approaching software development, and some people may be resistant to change
- Perception of additional work: Some people may view TDD as adding an additional step to the development process and may be concerned about the additional time and effort required
- Fear of failure: Some people may be afraid of failing when using TDD, as it requires writing tests that verify the functionality of the code and make it fail in the first place because the test is written before the actual code
- Lack of understanding of the benefits: Some people don’t fully understand the benefits of TDD, such as improved quality and maintainability of code, just from the books and may be hesitant to embrace it.
It's a one way trip
But I want to give you hope and willingness to learn TDD, so I think it’s useful to understand why people that learn TDD never come back!
- Early feedback: TDD assists developers in detecting bugs and issues early in the development process before they become major issues. This saves developers time and reduces frustration. To give you an idea, I never had to debug my code anymore since when I learned TDD.
- Improved code quality: By writing tests first, developers ensure that their code works as intended. This enables them to write high-quality, maintainable code that is less likely to fail in the future.
- TDD boosts developers' confidence in their code. When tests pass, developers can be confident that their code is working properly, making it easier to make changes and add new features.
- Better documentation: Tests serve as documentation, making it easier for other developers to understand the code and how it works.
- Faster development: TDD helps developers write code more efficiently, as they can focus on writing code that passes the tests they've written, rather than spending time fixing bugs and debugging.
Go Deeper
Here are some resources you can check if you want to go deeper and learn more about Agile origins, values, and reasons that pushed a group of great developers to originate the movement.
Books
- eXtreme Programming: Explained - The book about XP, where you can find a practice called Test First which is the first seed Kent Beck wrote about the TDD approach
- TDD: by example - THE book about TDD by Kent Beck
- Growing Object-Oriented Software, Guided by Tests - a great book about testing in software and TDD
Online
- Test-Driven Development by Martin Fowler blog