Automated testing in game coding
So my musings so far today have circled around the idea of automated testing in game engines. Automated tests are a series of unit or integration tests that can automagically verify whether or not you broke your code.Here is a quick explanation of both types of automated tests:
Unit tests are tests that isolate specific areas of your code and rigorously test individual parts. They typically pretend that the rest of your code doesn’t exist (usually accomplished via Mocking frameworks) and when you think about it, isn’t that how you’d debug a problem anyway? An example would be “Does this function in the class return the values I’m expecting when I give it input?”
Integration tests on the other hand function to test your code “as it is” for lack of a better phrase. It tests how the classes and modules of your code work together and whether or not your “business logic” is correct. An example would be “When 3 players connect to the server, does the database correctly log their actions?”.
Now, in game coding the typical idea is to get the game done ASAP and cut corners wherever possible since time is money. By this, I don’t just mean what big companies such as EA, etc. do to pump out new games every five minutes. It functions for all game development to a degree; if your game takes 10 years to be built, you’re probably going to have an out of date game and you’ll have to re-code at least some of it.
Do automated tests truly add value though? If you are a one-man shop, your argument is probably that you know the code intimately and that you stick to your coding guidelines (Thanks to Ruben for the argument). What happens though if you need to modify a really complicated system 6 months after writing it (while not forsaking the codebase in your day job)? Is booting up the game 40 times to do trial and error worth it more than a 30 second run of your automated test suite?
It most likely depends on your perceived usefulness of the tests. If you are just writing unit tests to verify that setPosition(1,1) actually sets your X and Y positions, then there probably isn’t any advantage. You’re likely to waste time building up a nice collection of tests to verify what you know. If however, you are concerned that your A* algorithm is a bit fragile and you’re worried that the AI would try to do something questionable on the game board, perhaps it might be a good idea while you’re working on the code to have some tests.
Keep in mind though, that the idea is to be able to verify without a doubt that the pieces of your code work 100%. If you don’t write your tests correctly or if you don’t even run them, then you’re only fooling yourself. Perhaps you have a good reason for fooling yourself though; perhaps at parties you impress people by telling them you have automated tests in your game engine code…
Jake Seigel's Schemes 