Professional Test-Driven Development with C#: Developing Real World Applications with TDD

HOW TO INTRODUCE TDD TO YOUR TEAM

You might be wondering how a section on introducing TDD to your team is related to tools, but being able to change someone's core thinking is a valuable tool. We are asked this question so often and have debated it so many times that it simply boils down to this: Either you're working with people who want to better themselves by learning new processes, or you're not. If your workplace values quality and people over process, introducing TDD is easy.

Working in Environments That Are Resistant to Change

When you leave at the end of the day, the code you checked into version control is your mark on the project. If it does not work, you are responsible for it. TDD has an initial learning curve, but once you get past that, you will create code as quickly as ever. Even if a team is unwilling to change to follow TDD practices, you can change. Get past this learning curve on your own time by pairing with someone who practices TDD. When you are comfortable, slowly start implementing what you have learned about TDD into your projects. I suggest that you do not go back and refactor everything in your existing codebase; just start slowly and track metrics. Managers like charts, and when you can show them that the last release had 20% fewer defects than the previous one, you can tell them you implemented TDD on your portion of the project.

At that point, the manager will either be mad that you did this or happy that the system has 20% fewer defects. If the manager ...