Test Driven Game Development

September 15, 2009

Test Driven Development (TDD) has steadily grown in popularity among non-game programmers.  Despite this, it has not been widely adopted in game development.  Today I’m going to discuss why TDD is suited to games development and how it frees developers and designers to experiment with “finding the fun” without breaking core gampelay.

Example – Mario

Let’s begin with an example.  You’re writing Super Mario Brothers and want to experiment with how Mario jumps.  You can change the jumping however you like, but he needs to always jump at least 20 pixels.  Your unit test might look something like this:

void Mario_Can_Jump_20_Pixel_Gap()
Mario mario = new Mario();
mario.Position = new Vector2(0,0);


Assert.IsTrue(mario.Position.X >= 20);   // Has moved at least 20 pixels
Assert.IsTrue(mario.Position.Y == 0);      // Is on the ground

You are now free to make any update you want to Jump() knowing that if the test passes, your requirements of jump at least 20 pixels is met.  This is much easier than loading up a level, trying the jump and making sure it all works.


So why would you want to use Test Driven Game Development?

  1. Guarantee code works. With a full suite of unit tests you are guaranteed that your code does what it is supposed to do.  Bugs will be found as soon as they are introduced as tests fail immediately.
  2. Forces modular code.  Notice there was no mention of UI, controllers or rendering in the example unit test.  This “Separation of Concerns” is not only good design, it’s also required if want to have testable code.
  3. Allows you to “find the fun”.  Once you’re guaranteed that certain requirements are met, you’re free to experiment with gameplay to make it more enjoyable without breaking certain levels or unbalancing the game.  This also extends to giving designers more freedom when scripting.  Encouraging experimentation by designers without programmer intervention is invaluable.

Good and Bad

Some parts of game development are perfectly suited to TDD while others may cause more trouble than good.  Firstly the areas that would greatly benefit from TDD:

  1. Game Engine.  Have a list of features/API exposed that is perfect for unit testing.  Unit tests serve as code documentation with code samples of usage.  It helps reduce the changes of introducing breaking changes to new build of the engine.  Performance tests can also be included.
  2. Core Gameplay.  Designers write up tests for core gameplay and formalize game design into testable units.  Again, this frees designers and programmers to experiment without breaking core gameplay.

The main area that TDD doesn’t fit is in UI and rendering:

  1. User Interface/Rendering.  Even outside the games industry, UI is difficult to test with unit tests.  This is particularly true for 3D UI’s.  This issue can be overcome with a good separation of concerns.  Keep UI and rendering separate from game logic so testability is still high.  One solution is using the MVC pattern for your game engine.  I will discuss this further in a future blog post.

Basic Tips

Below are some basic tips that will help get you started with TDD if you haven’t used it before.

  1. Keep tests short – test only one thing in each unit test
  2. Keep tests fast – run entire test suite in seconds
  3. Keep tests thorough – use code coverage to determine what is and isn’t tested, making sure all critical code is tested.


I’ve touched briefly on why Test Driven Development works well with game development and I encourage you to read further into TDD if you have not used it before.  As usual, I’d recommend picking a small project and experiment with TDD.  Perseverance is key as it may seem as though things are slowing down, but as a project grows and evolves your efforts will be rewarded.

If you’re currently using TDD for your game I’d be interested in hearing your story.

For the definitive book on Test Driven Development, check out:

  • bleevo

    it says 50 pixel gap not 20

  • http://www.doolwind.com Doolwind

    Thanks Bleevo, have fixed it.

  • http://www.r2.com.au/ Cliff

    I’m not sure how well TDD will apply to high level concepts such as a character jumping. I can definitely see its use for Engine APIs, Helper functions, etc though.

    Take your example of Mario. Everything in that example is fine, except for the mario.Jump(Right);

    Normally you’d map that to a key, press the key and it plays out over multiple frames. Wouldn’t you need a specific function that tests Jump in this way as opposed to directly calling it? I.e. you need to block that call till the physics finishes for the test case, but during the game you’d just call Jump and immediately return, letting it play out over several frames.

    I guess you could pre-calculate his trajectory if you were using simple maths for your character movement, but what if you’re adding acceleration over time to his jump (your own physics)?

    What if you had a physics system using dynamic rigid bodies and adding forces? You’d need to let it simulate for a while until you know he’s done jumping.

    Perhaps in these cases you need to write extra code specifically for the test? Doesn’t this mean more maintenance?

    Just some thoughts :)


  • http://www.doolwind.com Doolwind


    I definitely agree that TDD applies really well to API, helpers etc, I think there is also validity in testing gameplay. The tests will certainly take a different shape and will serve a completely different purpose. Rather than just testing validity of the code they will serve as a pseudo-design document outlining how the designers expect their game entities to behave.

    Good call on the issue with my example. I’ve updated to include a call to Update(). I left this out originally for clarity but in doing so I’ve created more confusion :).

    “I guess you could pre-calculate his trajectory if you were using simple maths for your character movement, but what if you’re adding acceleration over time to his jump (your own physics)?”

    This actually leads into an interesting topic I’ve been thinking about lately. I’m a big fan of deterministic movement in games (specifically that at any time x, you know exactly where every game entity will be). I might even write my thoughts up in a future blog. The need arose when I was thinking about having tens or hundreds of thousands of game entities in a multiplayer match.

    “Perhaps in these cases you need to write extra code specifically for the test? Doesn’t this mean more maintenance?”

    You are correct that TDD will require a lot more code. Some put it in the order of 10x more testing code than actual production code. This is one of the reasons people don’t like TDD. From experience though, I find that the confidence and testability gained from the code easily pays for itself. It does bring up the interesting point of what happens if the test’s themselves have bugs :)

  • http://light.widgisoft.co.uk/ Chris

    You need tests to test the tests! :-D

  • Sargo Darya

    While testing of applications may help you hunt down bugs this is not a practicable approach in game design. As for the most games you’re moving in a multi-dimensional space where the player can do many things at the same time.

    Lets take your jump method as an example: You tested if the player jumps. What if the player now does make an attack while in air and jumps again? Are animations well-playing then? There is a lot you have to consider which would make the tests rather bloated. That’s why you invite some testers over. They see what the computer won’t see until you’re so genius and implement a ingame Kinect >.>

  • Pingback: Becoming A Better Game Programmer – Doolwind's Game Coding Blog

  • Pingback: Test Driven Game Development Experiences – Doolwind's Game Coding Blog

  • Pingback: Debugging is bad « Limegarden.net

  • Ken Lee

    I practice TDD in my game development;
    I do unit testing on my development both UI and logic; It is useful to drill down the problem so that it can be solved and proven correct;
    Also it force you to write CLEAN code (cannot test highly coupled code from my exp.)

    there are some problems of TDD
    1. sometimes it is not easy to design those tests;
    2. need to refactor in order to test…
    3. need time and passion. (commonly think tests are extra works)

  • Teppakorn Thanuthanad

    How do you test UI ,Graphic and Animation in Game ?
    (ex. Compare Picture with another)