Revisiting Test Driven Development
Test Driven Development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Many positive side effects can come out of this. It encourages simple designs, inspires confidence, makes it less likely to regress, provides a clear Definition of Done, etc. After the initial hump; which involves building infrastructure, learning the tools, how to write tests if needed, and catching up writing tests for existing code; TDD can also increase efficiency and improve the ability to collaborate on a piece of code. Most of all, however, it helps you deliver a product that meets the requirements.
I came across TDD in its current incarnation around 2005, or 2001 if you include XP’s “test-first” in the definition, or 1984 if you include my work at Ericsson emulating IBM equipment by writing all the tests first and then making sure our equipment exposed exactly the same behavior. However, it wasn’t until last year I actually tried modern TDD on a personal level, spending a few months working with a non-profit project based on User Stories, TDD, Ruby on Rails, and managing a small distributed team via PivotalTracker.
So, how did it go? Based on many years as a developer, I know enough to be really dangerous and design things in my head and jump right into the code and (mostly) get away with it. Initially, after the curiosity around the test framework faded, I struggled with writing the stories and tests well enough and the code coverage decreased. As the project grew and the requests from real users entered the picture, the penalty for skimping on the tests also increased and my confidence in the codebase decreased to the point where I called a time-out to catch up with missing tests and brush up the poor ones. It was well worth it and allowed me to add or change features and refactor with confidence again. Verifying that things still work by typing a few words into the terminal and looking at a nicely growing string of (in my case) “test passed” messages is priceless. Based on how the tests were structured and implemented using high-level tools, it also made it easier to communicate with non-developers about the desired behavior of the system since the requirements were literally translated into reasonably easy to read tests.
In case you are interested to learn more, I’ve added links below to six TDD lessons. The total time is about 8 hours. Well worth it if you are considering using TDD or just have the curiosity bug. It will tell you both why TDD can be a good thing and show you how to do it as well.