Pages from my TDD Diary

TDD (Test-Driven Development) can be a hard-sell in many work environments. I said as-much in a previous post. The main problem lies in figuring out how to calculate the concrete time costs of TDD versus the abstract (but real) benefits.

While it’s easy to track the costs of TDD with a timesheet recording the amount of time spent writing tests versus production code, measuring the benefits in a measurable way takes a bit more creativity. My approach to measuring the benefits of TDD in my own code is to keep a journal of moments of when I think I have reaped benefits due to TDD. This is, of course, a very anecdotal approach to measuring the benefits, but it does provide a basis for tracking effects of TDD that would normally go unmeasured.

To give an idea of how this documentation goes, I’ll present a few entries from my TDD diary, a log of events in which I felt the benefits of having produced my code using TDD:

6/18/2012 Implementing Preallocate on Pool<>
Created trivial test of item counts, expected it to pass
Implemented Preallocate but it didn’t pass
I had made a dumb error by calling the Item allocator directly instead of through the get item function
Caught my dumb mistake, yay!

6/18/2012 Implemented updating list of actors, but found problem when updating actors added other updating actors (like bullets)
Thought: “Great, I probablly need to change the interface for my updating actors list”
Had test for 3 cases related to said list
— Insert updateable increases count
— Inserted updateable updated on list update
— Changing updateability of object in list moves it to update list
With the tests in place, I found that I was able to implement temporary holding lists without changing my interface at all

6/24/2012 I think I can attribute this to TDD: using TDD, my actor update logic ended up being decoupled in its own class instead of being just part of a larger “engine update”
This decoupling was motivated by testing ease, but it made implementing a pause system for my game trivially easy because I could instantiate an actor updater just for
in-game (pause-affected) actors while allowing other actors to be unaffected by pause. Had I not been using TDD, the oversight of not providing a convenient way to tick certain
groups of actors might have meant a lot of re-work.

6/29/2012 I found out that my scenes wouldn’t wait for the previous scene finish transitioning out before activating. I found the bug and fixed it, but had a slight logic error.
My test of standard scene functionality caught it. This way, I fixed it before even having to run the code in game to test.

Given events of TDD benefit like the ones, I can estimate the the amount of that would have been lost had I not been using TDD. This gives me a number that I can compare against the actual time I spend writing tests and help me figure out how well TDD is working out for me.

Share this Article:
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Print