Testing, Testing, Testing, 1,2,3…

With each game release I’ve noticed I’ve committed less and less time to writing the ‘fun bits’ and more time spent trying to mitigate complexity and find ways to make as many things as testable as possible. I guess that’s the nature of the beast once you go beyond your average ‘asteroids’ clone. With the recent announcement of SFT getting asynchronous play in the coming months, I’ve been scoping out my dev schedule for what needs to happen to make it reality, and the only issue that I keep circling back to is “how the hell do I make all of this testable/bug free”. Sure, I could write the async frontend and backend and just do some “dry runs” on a few VM clients, but I’d lose sleep knowing full well that wouldn’t cover even half the potential bugs or edge cases. I use to reserve testing for server-side components, core game logic, but our games have grown to a level of complexity that I can’t ignore the UI/animation layer anymore in regards to testability.

The core logic of the game is fairly well unit tested. But the UI/animation layer on top of it has less than ideal integration testing. That layer has tiny bits of interface logic that has grown quite complex despite most of it not really touching the actual game state. It has sufficed for now, but it’s increasingly clear that it needs to get refactored, maybe in some cases re-done for easier integration testing if I want to move the game from “real time only” to “real time, async, and seamlessly transition between the two”. On top of that, I just recently moved SFT to Unity 5.x which has cropped up a lot of bugs on the UI layer, and are increasingly hard to hunt down. Adding in integration testing after the fact is definitely not the best way to go, but I’ve gotta make do. The show must go on!

Leave a Reply

Your email address will not be published. Required fields are marked *