Much to my shame, I have never written a proper unit test, only small unorganized test programs that I would then dispose of after the test succeeded. I don't really have a clear idea of how unit testing should be performed in a game project. (My language is C++.)

Should I have a separate project for each subsystem in my engine and an associated test with it, and then have a bigger project/ solution that builds the actual engine? Say for example I have the event module in my engine; how should I handle that?

  • \$\begingroup\$ interesting question, when you develop you engine, it's pretty easy to test functionality, but what about large project in game test? \$\endgroup\$
    – Yevhen
    Commented Jan 24, 2012 at 9:02
  • 2
    \$\begingroup\$ Not a shame: unit-tests are not automatically a good thing. \$\endgroup\$
    – o0'.
    Commented Jan 24, 2012 at 13:11
  • 1
    \$\begingroup\$ If you've never tried using unit tests, that is definitely a shame. \$\endgroup\$ Commented Jan 25, 2012 at 0:25

3 Answers 3


First, you'd need a unit testing framework. In the past I've used UnitTest++ and Google Test. The former is very lightweight and the latter is more featured but somewhat more cumbersome. It integrates well with Google Mock should you ever need that sort of thing. There are of course many other options: see this list (by the eventual author of UnitTest++) and Wikipedia for example.

Unit testing is about writing focused tests to stress particular isolated independent bits of code ("units") under various scenarios. While in some cases you can unit test everything, it's usually not practical to achieve 100% coverage and, especially in games, can be quite difficult -- it's arguable whether or not unit testing your renderer output is in any way meaningful, useful, or a "true" unit test regardless.

It's important to remember that any (automated) testing is better than no (automated) testing. So you shouldn't stress too much over the fact that your tests aren't "true unit tests" and be proud that you simply have tests. Unit testing frameworks are usually useful for building looser, "non-unit" tests as well since they include functionality for packaging tests and reporting failures uniformly.

I would encourage you to resurrect your old tests and build them into a test project using one of the available frameworks -- something you can easily run from time-to-time (or automatically as part of a release or integration build) that runs all your tests. Write new tests for bits of code as it becomes apparent they would be useful to you, for example if you discover a subtle bug you could have detected with a test, you can add one to catch any regressions you may make in the future.

You will probably find that it's mostly your lower-level utility code that is amenable to unit testing, in games. That's fine -- that's foundation code that could disturb a lot of higher layers if it breaks.

You won't go to programmer's purgatory for not having tests for every little function and logical gate in your codebase, so don't spend more time than you need on writing tests. If you have to think harder or spend significantly more time writing the tests for a module than it took you to author the module in the first place, you may be wasting your time. Unit testing -- testing in general -- is a tool you learn to use appropriately to help you, not a chore you have to perform for everything.

  • 3
    \$\begingroup\$ If you have to [...] spend significantly more time writing the tests [...] than it took you to author the module ... Then your module is too complex. Simplify it now, you'll thank yourself in the future! \$\endgroup\$ Commented Oct 30, 2012 at 2:55
  • 3
    \$\begingroup\$ @Jess A module that is disproportionately difficult to test does not necessarily need to be simplified. There are many areas where unit testing is simply not a good use of time. This includes graphics, where output can vary a good deal and still be acceptable; code which is unlikely to change in the future; or code where the kind of abstract, de-coupled design that would be needed to facilitate unit testing is much uglier, more error prone, less performant, or less intuitive. \$\endgroup\$ Commented Jan 15, 2013 at 0:24
  • \$\begingroup\$ @rodarmor - agreed. There is a sliding scale of what is appropriate and what is not. As with all these kinds of answers, one size does not fit all :) \$\endgroup\$ Commented Jan 15, 2013 at 9:17
  • \$\begingroup\$ For UnitTest++ go to github.com/unittest-cpp/unittest-cpp. Everything else is out of date. \$\endgroup\$
    – Markus
    Commented Sep 17, 2013 at 11:15

There's a great series of blog posts about using TDD and unit testing for game developmnent here: http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1


A "unit" is the smallest testable piece of code, typically a single function or class. A unit test is another piece of code that exercises that unit of code to ensure it behaves as intended. A single code unit may have many tests, in order to cover all cases.

Typically, tests are not included in the main build of a project. Rather, there is a seperate build configuration for testing that includes all the test code and produces a program that runs all the tests and reports the results. A testing framework will provide all the scaffolding for this and is recommended, though not strictly necessary. If you are totally new to testing, you may be better off at first writing your own ad-hoc test rig, to make sure you understand everything that's happening.

Cover as much code as you can with tests, prioritizing code that you are not confident about, or code that is fragile and may be broken by future changes. You should run the tests often, ideally after every code change.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .