Today’s dev diary is on the yawn-inducing subject of unit testing. I’ll be very honest here. I don’t like testing. It can be mind-numbingly boring work at times, And yet as much as I loath to admit it, it is an essential tool in developing software.
I really properly learned to do unit testing during my time at Evolution. Unit testing is a part of the software testing procedures that was repeatedly bashed into my brain during my software engineering undergrad courses. While I understood the theoretical reasoning behind its usefulness, it wasn’t until my time at Evo that I actually saw it used effectively in practice. There’s a certain irony that it was at game company where I finally learned to wield this skill effectively, game development being usually regarded as the antithesis of proper software engineering practices. Go figure.
Anyways, unit testing is annoying to write, but useful as hell when done properly. You essentially write small pieces of test code to validate individual features. The goal is not just to prove that your code works as intended, but to ensure against someone accidentally breaking that piece of code 6 months down the line. Once you’ve set up an automated system to run through your suite of unit tests on a regular basis, it’s easy to catch a failure which would have otherwise crept into your codebase unnoticed. Unit testing is however very limited. It’s great for ensuring a matrix multiplication always works as expected, but it’s effectiveness drops rapidly as the size of the “feature” you are testing increases.
Which is what I ran into last week. I’ve got a decent set of unit tests for my low level math libraries, but I never bothered to set up a suite of tests for my physics simulation. After implementing a few algorithms for a new feature, I spent the better half of a day trying to figure out why it wasn’t behaving as expected. I eventually realized that I was wasting my time, and needed to put together a better testing environment to verify the correct operation of some of the more complex features I was writing. These features couldn’t be tested algorithmically with code, but needed to “look right”. I needed visual tests.
The best example of visual tests I’ve seen so far is at my last company, Havok. There are hundreds of test demos for the physics engine that show off every conceivable feature or special case. When drastic changes are made to the codebase, one can quickly verify that a feature like continuous collision detection on SPUs still works correctly through visual inspection of a specific test demo. Having an environment where one can quickly implement new tests and verify features is invaluable to the development process. This is why I decided late last week to adjust my current plan, and invest time now to implement a solid test environment. I won’t be spending weeks on it, as I’m trying to stick to a relatively tight schedule, and my development focus is on rapid prototyping. But a short term investment now will greatly simplify implementation of some of the new features I will add.
Work Done Last Week
- The first part of the week was good. I was a lot more productive then in my first two days of the previous week. I put together long term requirements for my project, and simplified my task planning. I am still experimenting on different methods for project planning (but that’s a post for another day).
- In the middle of the week, while implementing a new major feature, I discovered a major bug in another important piece of the code. I spent a bit of time trying to fix it but was unable to.
- I continued with the implementation of the new feature and completed it, at least algorithm-wise, but it was completely untuned.
- Instead of wasting tons of time debugging it, I switched focus to setting up a solid debugging environment so once implemented I can rapidly fix these issues. While it delays my short term goal, luckily, it’s one of the tasks I need to do anyways, so I’m not wasting any time. If anything, I’m saving on wasteful, slow debugging tasks.
Work Planned This Week
Continued implementation of a good visual debugging environment and a suite of tests. I also plan on finishing the implementation of the new feature I worked on last week. We’ll see how that goes.
Related posts:
Leave a Reply