Skip to main content
Game Development

Automated testing is a must in gaming – here is how to get started

Henry Lunabba
Henry Lunabba – Metacorean with a great beard and shirt
Henry Lunabba

Games are one of the most difficult things to test I’ve been involved in, and one of the reasons for that is that the user journeys can be so complex. I’m not saying other industries, such as banking, wouldn’t be equally complex, but for instance in banking the user journey has a start, clear steps for progression, and a tangible end result. Whereas with games the journey has a start, but the end is typically non-existent, or there can be an endless amount of ways to get there.

With mobile games that have a monthly release cadence, you basically need to ensure that both existing and new features and events work for your players every month. When new content is added to the game, the number of existing features increases continuously. Therefore, the list of things that need to be ensured just keeps getting longer and longer as the train keeps rolling. The solution is not to have more people to do the testing, but to automate some of that.

It’s 2025. We shouldn’t anymore ask whether we should do automated testing in gaming. The answer is not just that we should definitely do this in gaming, but also that we must do it to stay afloat. In something as complex as a game, developed at supersonic speed, the only way to test enough is to rely on extensive automated testing.

To manage, you need to break the entity into pieces and implement the necessary tools to have an extensive amount of automated regression testing throughout the test levels. Sounds complicated? Fear not – let’s dig in together.

Utilize the frameworks that are available, or build your own

To kick things off, we luckily have a lot of frameworks to help with building automated testing. Unity for instance has built-in and open-source frameworks available. Depending, of course, on your API architecture, there are plenty of ways for tools like REST to exercise tests against your backend API. To add to the list, there are different options available for testing from the UI.

Alternatively, you can build something on your own that fits your exact needs. Embarking on this journey is far from easy, but we are fortunate in this industry to have many smart people who can make it happen. While building testing frameworks on your own requires time and effort, if done in a smart way, it can quickly pay off, with benefits that only grow over time. Imagine if every build you produce and distribute from your Continuous Integration (CI) had already passed extensive unit and integration tests, and your automated UI tests had played through your FTUE (first time user experience) and most of your core features. Wouldn’t that be great?

From Lego blocks to automated tests for user flows 

There’s not much to debate around automated unit and integration tests, but automating system tests is where it gets tricky. Automating system tests should be done so from the get-go.

For example, if you decide to start building your own system test framework, it most probably makes sense to design a flexible architecture, i.e., have common core components that can be utilized by any game, and a game-specific layer on top of that. For the highest level of automated testing, it would also make sense to separate the framework from actual test implementation so that you don’t end up alone with implementing and maintaining all automated tests.

Instead, strive to build a machine that people on the feature implementation team can use to automate their own tests. In our case at Metacore, we implemented a keyword-based framework that uses Lego block-type keywords for every player-facing action (i.e., navigating the UI, clicking a button, merging things). Basically, a non-programmer can use our tool to create tests based on a sequence of blocks that can practically run any player-facing user flow. Down the line, when new features are added, the game programmers can actually implement new keywords to support these in our defined format.

With this approach, your automated testing is not limited to anything else but your own imagination. Furthermore, once the machine can run player-facing actions automatically, you can actually use it to test different types of performance tests and record e.g. device memory, CPU and GPU consumption.

Automated testing is an ongoing maintenance process, but well worth it

While automated testing has a lot to offer, it’s not something that can be established once and then be left to operate independently. Your framework, keywords and most importantly your tests need to be maintained. This is where the true benefit of a good dynamic architecture truly comes to play. At Metacore, if a UI navigation is changed in the game, we update the keyword, while all other tests using that keyword don’t need to be updated. So fixing it in one place, fixes it in all places.

Automated testing allows you to build coverage in unit tests, ensure that bigger, logical pieces work together flawlessly in integration tests, and eventually have the means to automate the testing of your core functionality from the end-user's perspective. When all that runs automatically in your CI for all your builds, the QA team has a chance to focus the time they have to test things that are too complex or impossible to automate. They’ll also have a chance to focus on the end-user experience, which, at the end of the day, is why we do all this testing in the first place.

The gaming industry is still quite young. There’s no time like the present to start building practices that can impact how things are done in the future. Planning your testing practices well from the get-go – and automating the testing extensively – are the way to go.


Interested in reading more about QA in games? Dive into planning and the testing pyramid.

Henry Lunabba is a Project Lead at Metacore. He’s spent almost half of his career in quality assurance (QA for short) within project, service, and people management—and now, in games. In this blog series, he will guide us through the lessons he has learned about managing (and sometimes, just surviving) chaos when developing new systems and launching new products.


Related content