Implementing TDD: Advice from the Battlefield
Changes are hard. I recently mentioned that. But changes are also necessary. I will now share with you some advice I have about the subject of implementing a change - starting to use unit-tests and TDD at your workplace.
- You should have some experience with unit-tests yourself before moving your entire team to TDD. Is the architecture your team using even testable? Can you understand the usage of a mocking framework? If you don't come with the knowledge to the team, you're in a world of hurt. Remember, this is a difficult change which can't be rushed. You should be prepared.
- It won't happen by itself. The first thing you have to understand is that writing unit-tests is something that most developers will prefer to not do, at first. I expected that I will just tell the team to start writing unit-tests for all their methods and they will. I figured they might struggle, but that things will work out. That was, of course, very silly of me. Writing unit-tests is hard at the beginning, and it takes time to see the benefit of this (not too long, though). A developer won't do a difficult task when he can't understand the benefit from it. It's a simple as that.
- It will be much easier for the team to start writing tests if they have whatever supporting frameworks and base classes they need ready to work.
- Examples are important. You should be able to present actual tests you wrote using the above mentioned frameworks, to production code. This is crucial. At first I tried showing the team an example of writing and testing a Stack<T> class. That was not very effective, as it isn't the type of code we usually write (DB access and business logic). The team should have a real-world example to use as a reference.
- Make sure the importance of writing tests is understood. Prioritize writing tests over writing new code. Make them understand that a piece of code is not complete until it is fully covered by working tests.
- It might be a good idea to set a week aside for just working on the first few methods and their tests. Dedicate most of your time in this week to provide assistance and to perform code-reviews on the code and its tests.
- Don't forget to setup daily builds which will run the tests periodically.
- Don't be discouraged and never give up, even if the team shows resistance to the move. Even if they can't see the point now, I promise that before long they will be telling how many bugs they were able to prevent, and how great it is that you don't have to be scared of changing old code. They will feel good and proud to see the green bars of passing tests.
- Expect the chaos. It is a part of every change.
My team has yet to complete the move. We are still learning the ins and outs of the method. Still, I hope the hard part is behind us, since as of now almost everyone has written working and reviewed tests for all their code in the current release. If you're interested, we're using VSTS for writing the tests, Rhino Mocks for mocking, and TFS for integration.
Good luck.