Why you should unit test your games (at least for some parts)
In order to solve problems in a code base, engineers often need to have large chunks of it stored deep in their memory. When colleagues ask a question of where something is in the code, you want to be able to answer them. They also expect that of you.
You are each other’s wikipedia in a way. Neat.
However, as the code grows, you slowly start to forget the tiny details and think of the code more in abstractions. You start to talk about modules, interfaces and systems instead of particular classes.
“Oh, yeah – you can find that in the input module.”
as opposed to
“Look in InputManager.cs at line 57”
This is fine. That is how it’s supposed to be. The problem comes after, when your code base is huge and the first bug reports start rolling in.
The detailed perspective you used to have is gone, or worse yet – the person that programmed this particular code does not work on the project anymore. Let’s say you get this report:
User Report: “My equipped weapon doesn’t give as much damage as it says in the stats.”
You find the problem, fix the bug and all is well. A few days after, a colleague asks you:
“Niklas, didn’t we fix that bug a long time ago where the weapon damage was too high if you were having an armor debuff applied and using a low tier weapon at the same time?”
That’s what you thought as well, but you agree to look into it. After a half an hour of debugging or so, you notice that the other weapon damage bug you fixed a few days ago actually caused a regression and opened this bug right up again.
Once your code (and team) grows, this kind of thing will happen increasingly. The fine grained details of the small stuff inevitably disappears, and unless you have a system in place to nip these things in the bud you will continue wasting time fixing stuff you already fixed.
This is what unit tests do. You create a test on the functionality you designed your class for, and if there is a bug noticed there – you create a test case for that specific bug.
That way, you can set up so that you get a slack notification when a test is failing, or better yet, your game won’t build at all.
The book ‘The Pragmatic Programmer‘ by Andrew Hunt and David Thomas has a fantastic tip/principle that I like:
“Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.”
I know that games are a bit difficult because there’s so much changing all the time, but to me that’s no reason to scrap unit tests all together. Find an amount or a rule set that works for you.
For example – If you decide to write a JSON parser. Test it! The JSON Format definition won’t change in the near future. And if it starts to break, the unit tests will tell you.
Do you automatically test your games? What are your experiences with it?
Thank you for reading! If you liked this type of post, please let me know! That way I can get a sense if I should do more of them. Also, If you have any comments, observations or perspectives about this – please talk to me on twitter!