Early in my programming career, I considered TDD (Test-Driven Development) a panacea for writing good code.
It makes some sense:
If you test every atomic piece of code, then all your code should work if all the tests are passing.
The problem with this view is very apparent in game development.
In games, bugs are rarely due to a specific piece of code being poorly written.
The bugs you see in games would be the unhandled interaction of perfectly working code.
Say you have a double jump feature, which increases your characters velocity.
And you also have a dodge feature that increases your characters velocity.
The bugs I would expect would be if you dodge at the exact time you double jump, massively increasing velocity.
It’s for this reason, as well as a healthy dose of laziness while working on personal projects, that I usually end up ignoring writing unit tests (for games).
Well today I ended up debugging issues that pretty much boil down to “maybe unit tests are useful after all”
In yesterdays Debugging Music Strategies, I expected that today I would be testing CreateMotif functionality.
Nien. Today I was testing the data object CreateMotif uses in its functionality.
And I run the gamut:
- Values being unassigned
- Literally an infinite loop
- Inverted logic where the highest value was set to lowest, and vice-versa
All of these are the exact reason unit tests are useful. In fact, its the kind of thing that makes TDD attractive.
Am I going to write unit tests?
No.
Unit tests in games are jank as hell anyways, and I am not interested in spending literally several days figuring out how to setup, run, and automate a unit test framework for Unreal.
It’s just one of those things I know is not casually done.
But I do feel a healthy dose of chagrin that the issues I’m hitting today are the kind that unit tests fix.