Copy LinkCopied!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.

Those 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 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 to write with some level of certainty that the code will work as intended.

In games, TDD is not as useful than 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.