It’s no secret that I’m a big fan of unit tests. They provide a huge safety net for refactorings, double check the code logic, and prevent code rot. In addition, unit tests written through Test-Driven Development help define the architecture and keep programmers happy. They’ll even catch a bug or two along the way, but if you rely on them as your only way to catch bugs, you’re in for a surprise. Continue reading
Test-Driven Development
There are 13 posts filed in Test-Driven Development (this is page 2 of 3).
UnitTest++ v1.0 Released
We grabbed the best features of each framework and created what we think it’s the best C++ unit-testing framework out there (for our needs anyway). We took the results and put them up in Sourceforge under a veryunrestrictive license, and that’s how UnitTest++ was born. Continue reading
Backwards Is Forward: Making Better Games with Test-Driven Development
We have all experienced how development slows down to a crawl towards the end of a project. We have seen first-hand the difficulty of squashing insidious many-headed bugs. We have wrestled with somebody else’s code, just to give up or fully re-write it in despair. We have sat in frustration, unable to do any work for several hours while the game build is broken. Code can get too complex for its own good.
See how doing something so apparently backwards as writing unit tests before any code can help with all those problems. Continue reading
CppUnitLite2 1.1
At this point, we have been using CppUnitLite2 for a year at High Moon Studios doing test-driven development on Windows, Xbox 360, and some PS3. It has been used to unit test libraries of an engine, pipeline tools, GUI applications, and production game code. Continue reading
Stepping Through the Looking Glass: Test-Driven Game Development (Part 3)
After reading the first two parts of this article, you should have enough information to strike boldly and apply test-driven development to your projects. At first you’re likely to find that the road is somewhat rough and bumpy, though. How do you break up this module into something testable? How can you prevent your tests from becoming a burden to maintain? What exactly should you test?