Test Infecting Your Team
Recently, a simple question was posed to the Yahoo Test Driven Development (TDD) group.
I've seen situations where the person on a team you would single out to infect produces a high level of quality of code without unit testing. In this case you have to show the leader that their team could produce more value if they were to adopt unit testing, even when the difference it makes for them is negligible.
How would you do this?
Initially, it's easy to argue that it's not necessary. If a developer is already producing high quality code that does what it's supposed to, then it's easy to justify that TDD isn't necessary. There's a cost to TDD, and many of us have heard the argument that TDD slows a developer down.
Thankfully, Joshua Kerievsky chimed in with the sensible words of wisdom that shed light on the importance of TDD...even in situations where developers are able to produce high quality code without it.
A "high level of quality code" is great, yet most software lives on and on and people expect to add/modify features in that software or debug it. How much will the maintenance costs be without unit tests? How much more risk does that add?
Most folks just look at today, not tomorrow. It's important to consider the full cost of not writing unit tests.
Of course, the point here is that TDD provides benefits beyond testing. While TDD is just one way to prove that our code works today, TDD also provides the courage to refactor the code tomorrow. It provides developers important feedback on the system wide impact of their change. It serves as a form of executable documentation for developers responsible for maintaining the code going forward. While there is a short-term cost to investing in TDD, the real benefit of TDD is long-term and is well worth the investment.
For reference, here's the Yahoo thread.