# How does one do unit testing in a game engine?

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?

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

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.

• 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! – Jess Telford Oct 30 '12 at 2:55
• @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. – Casey Rodarmor Jan 15 '13 at 0:24
• @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 :) – Jess Telford Jan 15 '13 at 9:17
• For UnitTest++ go to github.com/unittest-cpp/unittest-cpp. Everything else is out of date. – Markus Sep 17 '13 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.