Chapter 12. Adopting TDD
They say that time changes things, but you actually have to change them yourself.
Andy Warhol
You’re reading this book, so it’s likely that you’re already interested in TDD and quite possibly already in the process of adopting the technique in your work. It’s also likely, however, that not all of your co-workers share your interest in test-driven development. Having the rest of the team adopt test-driven development would obviously support your own adoption, not to mention the benefits to the organization as a whole—which is why you’d probably want your colleagues to get infected with the test-first bug as well. This chapter’s purpose is to help you both in your personal adoption of TDD and in getting others aboard the adoption train.
We won’t focus too much on TDD itself, because the dynamics of personal adoption are universal regardless of the actual change being suggested. What we’re going to cover are factors that influence our ability to lead change on a personal level, whether for ourselves or for our colleagues—colleagues who are possibly on our client’s payroll, if we’re in the role of an external consultant.
Let’s begin by discussing what it takes to adopt a technique like TDD.