Out Of The Stone Age

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.

1. 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.
2. 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.

I walked into the pet store the other day and was confronted with an unbelievable dilemma. My boss needed some cat litter, but there were at least 20 available brands. My mind shuddered. They ranged from coarse grained to fine grained, scented to unscented, single cat to multi-cat, etc… There were the commonly used, well respected brands, as well as the off brands which promised to be just as good. There was the small 5 pound bags and the giant 80 pound bags.

I immediately went home and started searching the blogs and forums for the ideal litter. I was confronted with a barrage of information, as well as some angry critiques:

“Anyone who doesn’t use the coarse grained scoopable Tidy Cat is a Moron! There is no way a fine grained litter will scale to multiple cats without tracking. It just isn’t possible. I’m so sick of this new fine grained, scented crap that keeps popping up. This is a forum for SERIOUS CAT OWNERS. TAKE YOUR CAT HOBBYIST ASS SOMEWHERE ELSE!”

I sat in my chair pondering my dilemma, thinking that I might as well go with the Tidy Cat, because it seemed that was what the majority was doing, and it worked very well. Although there was the occasional complaint that the price didn’t really reflect its value adequately.

But then I remembered, my boss only has one cat and will probably only get another after he dies, so I don’t really need the scalability. But I worried about getting the cheap stuff because of the reputation of people who use it. They are often called hobbyists, or amateurs. Sometimes they are even told they don’t care about their cats! I didn’t want myself or my boss to endure that kind of labeling.

I set off for the store bound to get the good stuff, but while heading down the aisle I had an epiphany: What if the cheaper, newer stuff is really GOOD ENOUGH for 1 cat and maybe even 2 or 3? I knew my boss was away for the weekend so I decided to buy the new stuff, let the cat shit in it and see if it scaled to his odor. I could always get the good stuff later.

Kinda reminds you of the REST vs. SOA debate, doesn’t it.