Test Driven Development or TDD is very common in modern software teams but is not universal. Many career developers are only just stepping, blinking into the light of what it takes to be a successful developer in today’s software projects. There are many stones yet to be turned which surface more developers who are still to go on the TDD journey. This post is about the things you might need to do to walk the path to TDD enlightenment.
If you want a team to do TDD the very last thing you should do is mandate it. It is a bit like telling your child to clean their room. You know by telling them to do something, it will be the very last thing that they will do. No one likes being told they have to do something. At best the team will go through the motions, make token efforts and blame you when every task take twice as long because “we have to do TDD”. At worst you will have downright descent where every discussion becomes an argument about why TDD is a bad idea.
If you want a team to do TDD they have to want to do it. You have to create a movement
Take the first step
You’ll often work with codebases with little or no test coverage. Spend time reviewing the code on your own or with other developers. Look for the core business logic and the parts of the system that are commonly used. Start adding tests around these areas yourself. Depending on your role, the type of project and the organisation you work for you might have to do this in your own time.
Find your first followers
Writing tests yourself will only go so far. If you are not careful your helpfulness will become a hindrance. For example, when someone starts to refactor the code base and finds that lots of your tests no longer compile. If you can’t create a following, you are just this mad guy causing lots of problems. So, be public about what you are doing and why. Pair with other programmers and show them how things work. If you do create a problem, drop everything and sort it out.
Move to the Tipping point
Once you have a few followers publically demonstrating what they are doing more people will join you. Use that time to make the process smooth. Is it easy to run the test suite and does it execute quickly? Fix problems you find so it becomes more difficult for people not to join in.
Cross the tipping point
Soon you’ll have more people involved than are resisting. The momentum your following generates eventually makes it harder for people not to follow. This includes ensuring that test suites run as part of a continuous integration setup and the code is refactored to make it easily testable. The codebase will become simpler and easier to maintain. Over time clear design patterns will emerge… patterns that are easier to test.
Soon the advantages of unit testing will be clear to the team and those interacting with them. The team will be more confident maintaining the code, many existing code issues will have been identified and resolved. Perhaps the tests will have stopped mistakes finding their way into live.
And here is the rub, I haven’t written about TDD yet. Code that is more testable tends to make developers think about how they will test code as and (hopefully) before they write it. Your following will self-organise around the best way to provide automated testing and this may lead to TDD.
I never tell or even ask teams to do TDD. I don’t evangelise that red, green refactor is the only one true way. I have seen enough Test Induced Damage from teams that have done this religiously without really understanding what they were are aiming at. What I ask for is the team to be good engineers and provide some level of test coverage for regression confidence and start a journey towards regular stable and reliable releases. If TDD emerges from this then all well and good but TDD is simply a tool or a technique, it is not the goal.
This post and the idea of building a movement around automated unit testing is inspired by this TED talk. It is one of my favourites.