Test Driven Development (TDD) is a buzzword that enjoying an upswing in popularity at the moment. I think that a lot of developers know that writing tests is a good thing and that everyone seems to be saying that writing them first is the way to do it. So an initiative is started to do TDD either self-taught or with the help of a training course.
My first experience in a company that was serious about adopting TDD was to approach it the same way as any other project was done at that time. We analysed what the process changes were and, as a dev team lead, I wrote a 5 page document on the new process of writing any new functionality. It was a truly self-righteous document specifying a multi-phased approach of writing all the unit tests first against the interface diagram from a design document, getting it signed off, and then writing the code to make all of the tests pass. That’s test-first right?
Well, we kept at it for a while but in the end it became litigious and ultimately failed. So did the next three incarnations over the next year which swung from even more formal to a bullet point in the code review checklist, and even included the outrageous step of using a consultant. Eventually, we got there and we’ve never looked back.
This is what I’ve learned from that experience and from new experiences since TDD is not an isolated technique that can be bolted on to your process, but rather part of a way of working that assumes that you also can write good micro-tests, know how to refactor safely, know what to refactor and when, and that the developer(s) are empowered and supported in making hundreds of little decisions every day.
What I’ve found is that if you do pursue implementing TDD until it is successful, then these other parts of the working eco-system get pulled in the back door. As you improve your competency in one of the fields the other parts need improving too, leading to an overall improvement across the whole process.
Now if all this sounds daunting, fear not. Keep things simple. In fact the underpinning theme of all of this is reducing the amount you need to keep in your head at once. Refactoring tools raise the level of abstraction so that you don’t have to concentrate on copying/pasting/editing code instead of selecting a higher-order transformation to activate, such as “Extract block to a new method”. TDD also focuses on reducing this cognitive load by demanding that you make the smallest change possible to the code and prove that it behaves as expected before even considering the next move. So, if you’re considering all of this TDD-related goodness for your team, then this is what I suggest.
And, lastly don’t be afraid to talk to people and even get in some help. Adopting TDD and its related ecosystem will change how you do your work – but that’s the point, isn’t it? Change requires effort but it’s worth it.