Thanks For Catching Me
I learned about Test Driven Development recently and have been using it along with CXXTest for about a week now. I understood the supposed benefits, but in a very short period of time I have realized substantial actual benefits.
First off, by writing tests before I code I think of simple use cases for my code and understand it from a user’s perspective. This is fine in and of itself, but not necessarily that noteworthy. Once I code simple (maybe even throw-away) solutions to these tests I further my belief in my use cases. This may also sound nice, but this is certainly achievable with Big Design Up Front as well. And I don’t disagree, necessarily. Especially if you are a very experienced developer.
However, the test cases themselves are the biggest benefit of TDD. By coding these test cases I can provide a giant safety net for myself when I redesign my data structures or algorithms. Furthermore, by writing the tests first, I make sure they actually do get written. Therefore If I so desired I could code with reckless abandon and rewrite a class completely with lots of STL containers and algorithms, and by re-running my test cases I could ensure that the code still works the way it previously did. While this is not necessarily the “incremental changes” path advocated by TDD experts, it is a form of larger scale refactoring. This is what I did today, and the safety net I had created saved me in two distinct ways that I did not expect.
- A simple corner case: Several member variables were keeping track of state in my class. I needed multiple instances of these, so I wrapped them up in a struct and used a std::map to store them keyed on an IP address. However, after storing my variables inside the stl::map, I altered an algorithm I had written to organize the data in these variables so that it would be more coherent. However I broke a very simple corner case that I likely would not have noticed for at least a few days down the road. As soon as I compiled my changes and ran the code my test caught the error and it was fixed in a matter of seconds.
- Misuse of third-party code: First let me state that I consider the STL third-party code. Like third party code, you need examples to use it and experimentation to use it correctly. Although I have used the std::map class many times before, it has been a while since I’ve last used it. And thanks to my TDD safety net I was coding with reckless abandon. I made the classic mistake below:
std::map<KeyType, DataType> exampleContainer;
DataType extractedData = exampleContainer[someKey];
/* modify extractedData */
exampleContainer[someKey] = extractedData;
What I did was modify a copy of the data and attempt to reinsert it into the map. This is not how a std::map works. The correct way is to retrieve a reference to the data and just perform the modification. Once the key is associated with a value in the map, insertions fail. But the syntax of the [] operator does not allow for visibility of the failure. The correct code is below.
std::map<KeyType, DataType> exampleContainer;
DataType& extractedData = exampleContainer[someKey];
/* modify extractedData */
It is important to note that other tests in my test suite passed even with these code mistakes. Therefore a cursory manual test would have certainly passed over these seemingly glaring errors leaving them for much later in the debugging stage. Furthermore these errors probably would’ve percolated up into extremely odd behavior in the application, causing me to spend much more time debugging the program with gdb or print statements than I spent writing the tests in the first place. Even worse, they may have evaded me and made it to SQA, although unlikely 
By having this safety net in place the errors were caught quickly and corrected immediately. I am already enjoying the benefits of TDD and I encourage every developer to give it a try. Test Driven Development By Example, by Kent Beck gives an excellent introduction to the topic.
Tags: coding style, TDD