Personally, I love the concept of Test Driven Development/Design. I firmly believe that this development practice produces clean, testable, and maintainable software. I’ve worked in a few US Government contracts, and I must say that the practice is not very common in these environments. In the contracts that I’ve worked in, I’m usually the person pioneering this practice and I’ve found that spreading it to the rest of the team can many times be difficult.

I’ve encountered team members who do not believe in the practice and have a pathological concern that writing unit tests will make me slower. I’ve encountered people with multiple years of experience who cannot write effective tests. Worst of all, many people cannot make the connection of how TDD can be used to drive effective design. So, the question is, with these roadblocks, how can one introduce TDD to a team?

The most effective method that I’ve found is to hold lab-oriented brown-bag sessions with the team. The sessions are most effective when the instructor implements real, executable code using TDD. A common problem that occurs is that many instructor use common and simple scenarios to show TDD practices. For example, implementing FizzBuzz using TDD is a great exercise, but it is unlikely to change people’s mind about using TDD in your application. To combat this, the instructor needs to provide a domain applicable example of TDD in action. Implementing a feature for the application you work on has a much higher chance of influencing people’s mind about the effectiveness of TDD.

Most presentations people do tend to include powerpoint slides, graphs, diagrams, statistics, and all sorts of pictures and flare to explain why TDD is so great. This works great for managers and executives to look at, but when you’re asking a team to adopt it the more statistics and graphs you throw at them the less likely the team is going to embrace it. Developers like processes they believe in and are hesitant to adopt changes imposed by management. A TDD presentation should include a minimum amount of static slides, minimal diagrams, and minimal statistics. The presentation needs to include live coding demonstrations, interaction with the class (to present refactoring ideas or implementation details), and if possible, small labs that the class can participate in.

During these type of presentations, you may sometimes find that the architecture of your existing architecture may not be as testable as you may have thought. This should not discourage developers to adopt TDD as a practice. Instead, this should be taken as an opportunity for future Technical Debt cleanup. A class or component that is not testable now should by no means remain that way for the lifetime of the application. During your sessions, you may even be able to refactor those classes to present alternate, testable implementations. You can then compare and contrast the pros and cons of the old versus new code.

Introducing TDD practices into a team that has no previous experience with this process can be difficult. TDD must be adopted and embraced by developers. Management can allot for training sessions, brown-bags, literature, etc, but in my experience management cannot force the adoption of this or other software development practices. The most effective teams are formed when developers share a common vision for the software they are building. Eventually, best practices become self-enforced by the team members themselves through peer reviews, conversations, and overall knowledge sharing.