Test Driven Design

2025/12/27

Type
Learning Resource
Format
Glossary Article
Version
General
Subject Tags
Code
Assets
All else
Copyright 2016-2026, GDQuest
Created
2026/02/16
Updated
2025/12/27

Test Driven Design

Test Driven Design or Test Driven Development (abbreviated as TDD) is when you write tests before you write code. It defines a formal specification and makes it easier to know what code to write.

These tests are called "unit tests" - they are micro testing functions that verify the smallest piece of code possible.

The TDD process typically follows these steps:

  1. Write tests for the desired behavior of a small piece of functionality. This test fails initially because the corresponding code to implement the functionality doesn't exist yet.
  2. Write the minimum amount of code necessary to make the test pass. This code might be incomplete or inefficient, but it's just enough to satisfy the test.
  3. Run the tests to verify they passed. If the tests pass, it means that the code fulfills the desired behavior.
  4. Once the tests pass, refactor the code to improve its design, readability, and performance while ensuring that all tests continue to pass.

When all the tests pass, you're done. It's very satisfying, and in teams, very useful because everyone can use the code as soon as they know what it looks like, even if it doesn't exist yet. It also promotes the writing of isolated, independent pieces of code, so you can test them individually (that's why we call those "units").

If you have tests for most of your codebase, this is referred to as "code coverage." A "100% code coverage" means every piece of your code is tested. Of course that doesn't mean you don't have bugs. You could be writing useless tests, or the wrong tests. But TDD gives confidence and allows you to write with some level of certainty that the code will work as intended.

In games, TDD is not as useful as in general purpose software, because unit tests are difficult: in games, everything depends on everything else, so isolating a piece is not always easy or possible.

TDD might also lead to bloat, writing functionality and code that isn't necessary.

Instead, a similar, but potentially more useful pattern is used: Interface Driven Design. In IDD, you write code that uses a functionality before implementing it.

Become an Indie Gamedev with GDQuest!

Don't stop here. Step-by-step tutorials are fun but they only take you so far.

Try one of our proven study programs to become an independent Gamedev truly capable of realizing the games you’ve always wanted to make.

Nathan

Founder and teacher at GDQuest
  • Starter Kit
  • Learn Gamedev from Zero
Check out GDSchool

You're welcome in our little community

Get help from peers and pros on GDQuest's Discord server!

20,000 membersJoin Server

Contribute to GDQuest's Free Library

There are multiple ways you can join our effort to create free and open source gamedev resources that are accessible to everyone!