After over two months of deliberately attempting to adhere to the practice of Test-driven development (TDD), I started working on a sizable chunk of untested code. Here are some of my reflections on the contrast between tested and untested code.
TDD is an arduous process. When you’re coding up a solution, not only do you need to figure out what code needs to do, you are also forced to componentize the solution in a way that is unit testable, if only to make the test writing easier. This is especially annoying when you’re working on procedural functionality that doesn’t decompose naturally. This forced decomposition has its benefits, though, as it “encourages” one to produce simpler and more understandable code.
One of the other luxuries afforded by having tests is how easy it is to hand over code from one developer to the next. The test suite provides a very quick and comprehensive way to verify that existing functionality is not broken without the new developer having to be across the board with the codebase. Speaking of verifying functionality, the scaffolding provided by our test suite has allowed us to execute and complete major code refactorings in very little time.
But back to my experience with the untested piece of code. I couldn’t help feeling a sense of trepidation as I worked my way through. Maybe it was because it was unfamiliar territory for me. Perhaps it was because there was no way of me verifying that I hadn’t stuffed anything up without first fully understanding what it does.
But one thing is for sure, the last two odd months have made me very dependent on tests. Addicted even; which makes me wonder if that is a good thing.