Patterns of automated game testing: Screen Objects

When writing test automation for video games, especially end-to-end tests, a very important pattern to know is the screen object.

What is a screen object?

Screen object is a design pattern helping with test maintenance and code deduplication. A screen object is an object-oriented class that serves as an intermediary between a screen of your game and your tests. The tests use the methods of this screen object class whenever they need to interact with the UI of that screen. The benefit is that if the UI changes for the screen, the tests themselves don’t need to change, only the code within the screen object needs to change. Subsequently, all changes to support that new UI are located in one place.

Screen objects are actually inspired by page objects, their counterpart in the web testing world.

What’s inside a screen object?

As said previously a screen object is an object-oriented class. Inside this class we find the following:

Locators

Locators are special methods used to find UI elements inside a game screen. Every major game engine has its way to allow for finding UI elements inside some kind of hierarchy. Locators are methods that allow you to refer to elements you want to interact with without having to copy paste the same lookup code everywhere.

The two main advantages of using locators are:

• Improving the expressiveness of your code: often it’s not clear how an element is intended to be used. By using a locator you can give it a clear name.
• Reducing code duplication: if the element targeted by a locator changes, there is only one place where you have to update the code to change all your tests.

Probing methods

A probing method is any method that returns information about the state of the game. Often they will be predicates, that is methods returning booleans. But probing methods can be more complex and return any value, like the name of an item or the amount for a given currency inside the game.

Interactions

Interaction methods are the methods that will interact with the UI of your game. It can be a simple click on a button, but it can also be a complex set of inputs to achieve something specific.

Synchronization methods

Because web and mobile apps are almost all built on the same technology standards (html, css, javascript, android or ios native UI toolkits), most of the testing tools used to test them can take care of synchronization problems for you.

What are synchronization problems? Often you need to know when your application under test is ready to receive your input. For example you might want to click a button, but the button might not be rendered, or interactable.

On standard platforms like web and mobile apps, the underlying standards can provide you with this information. So the testing tools leverage that to avoid having you taking care of the synchronization between your testing code and the UI.

However, video games are not built on standards. Not only game engines are all very different, every game is differently constructed too. This means you have to write your own synchronization mechanisms when writing testing code.

That’s what the synchronization methods are for. They’re methods used to explicitly wait for something. For example if your game has a menu loading data from a server, this can take a few frames for the UI to be loaded properly. In this case you might have a spinner shown to the player. Your testing code needs to know when the menu is properly loaded before it can interact with it. Hence the need to write a specific method to wait for the menu to be loaded.

Example

Here is an example based on the Unity game engine:

using System.Collections;
using UnityEngine;
using UnityEngine.UI;

public class MainScreen
{
    // Locators are used to find UI elements
    public GameObject Root => GameObject.Find("Root");
    public Button ShopButton => GameObject.Find("ShopButton").GetComponent<button>();

    // IsActive is a probing method, more precisely a predicate
    public bool IsActive()
    {
        return Root.activeInHierarchy;
    }
    
    // OpenShop is an interaction method
    public IEnumerator OpenShop()
    {
        // Interaction is a custom class made for testing the game
        Interaction openShopInteraction = new Interaction()
            .Click()
            .Button(ShopButton);
        
        yield return openShopInteraction.Perform();
    }

    // WaitUntilActive will pause the testing code until the main screen becomes active
    public IEnumerator WaitUntilActive()
    {
        yield return new WaitUntil(() => IsActive());
    }
}

Conclusion

As you can see screen objects can be very useful to write test automation for video games that is easily maintainable.

However the main caveat is they’re focusing a lot on UI. It makes them very good for end-to-end tests, but less so for other types of tests, like integration or unit tests.

If you can’t easily write lean integration tests and need to go the end-to-end route, screen objects are a must.