On Hobby Coding: Test driven development
Backed up from a local Blogger export (6785516474014652721/6785516474014652721.html) on 2026-01-01.
I always had a focus towards testing. Every major commercial project that I’ve worked I have been pretty good about writing some kind of developer facing test suite not always before the meat of the code was written. What has really solidified the testing mentality for me was the last 2 or so years up until about a couple months ago I was an engineer completely focused on writing functional test code and stress simulations.
I took this job intentionally, not just because everyone I interviewed with completely impressed me technically but because I really wanted to stretch myself in this role. It has taught me a lot of new things about design and every day coding and it has really evolved my hobby coding as well. I don’t write exclusively test oriented code any more but I’m even more sold than ever on the benefit of approaching things from a testability angle.
Wikipedia has a good definition of TDD. Your milage may very. Personally, I usually write the ‘client’ functionality test and then implement either a no-op interface for it at first or something very basic. If I’m working on something new and complicated I spend some time mulling it over and drawing pictures first. If it’s adding some small functionality to existing I’ll do the simplest implemention.
During the time I’m implementing I’m always looking for ways to collapse functionality (ie. refactor) or simplify things. A lot of times you find issues before hand as you’re writing the test, things you didn’t think of when designing. Here’s some warning signs you’ll likely see:
- This code is totally not testable..
- If I could only get at that lower level thing, this would go way faster
- If I shared that dohicky than I only need to write n/2 lines of test code
- This is going to take some serious time.. do I don’t really need this?
These are all really net-positive things to discover early on. Most importantly.. these things are discovered before you write 2k lines of dense game library code. There are some real challenges to be solved here that are going to make you a better designer and coder:
- Proper layering of your code, decoupling and exposing multiple layers so they can be tested individually. This is a non-trivial design challenge to do correctly but done right is really great.
- Cutting down uneccessary feature-creep when you really actually don’t need something. When there is nothing left to remove you have the perfect product ;)
And at the end of the day, if you did a half-decent job you have a properly designed testable system that you can easily make changes to because you have a proper test framework for it. There’s more here but I’ll save it for other posts. Less theory more practice.