Automating your test states: an Introduction

Have you ever needed to test a feature you just implemented, and realised that you’d have to go through multiple steps just to get into a testable state? This is a situation I’ve frequently found myself in, and one that I’ve developed a simple and scalable solution for.

Game development is an iterative process, so when I have to implement a feature, I have to test it multiple times. While doing so, I frequently end up having to manually navigate through several prompts and menus before reaching the state where I am actually able to test the feature. Doing this multiple times can be a pain, so I developed a method to automate getting directly to a testable state, using Unity and our game, Disney Melee Mania, as an example.

Quick Entry into Matches

In Disney Melee Mania, there are several screens and buttons to get through before you can enter a bot match. This is the simplified flow:

With all the button-pressing, animation, and loading time added together, just getting into an bot match would take about 30 seconds at least. Test it 10 times, and we would have spent 5 mins just on repetitively clicking buttons and waiting for screens to load. That’s a lot of time that could be spent elsewhere.

So let us start with skipping the 3 splash screens; they were previously already skippable just by tapping, but why bother to tap when we can just outright skip them both? So with that, we’ve got our first task down:

1. Create a static bool at where the splash screen will show:

2. Set the static bool to true, and play the game in the Menu Item

That will give us the option to bypass the splash screen, or not.

With that out of the way, we are left with something like this:

Now on to the next step. The diagram shown above is actually a much more simplified user flow, so let’s go into more detail on how the Save Game screen actually works in Disney Melee Mania.

We can do something similar to the previous example:

1. Set up a menu item

2. Use a static class here for a boolean for direct match entry, as this would be reuse in other classes later too

4. In save game view we can automate the button presses with this

5. ConceitViewModel can follow a similar skipping flow to SplashScreenViewModel

After we are done, the Save Game flow should look something like this:

6. And finally, for the Lobby Screen to bypass the tutorial in the case we have a new game scenario.

With this, we have implemented via the Unity editor a quick entry to bot matches. These tools allow you to immediately choose which part of the game you’d like to test, and they also take you straight to there, hence saving a lot of time during development.

Final Flow

Force Selection

While implementing Characters and AI, I noticed that the tool above was kind of lacking. Here are some of the issues I faced:

• I would like to play against a specific AI to test their behaviour, but AI are random in Disney Melee Mania, so I would have to restart the game until I get that AI (or go into the code and remove the other characters from the pool).
• I would like to test a certain map to check that everything is set up properly. But similar to the AI, maps set up to be randomly selected each time you join a match.
• I want to use another character without having to break the flow to switch out my existing character. With the flow we made previously, I would need to go into the lobby screen to select my character before getting into the bot match.

But the tools we have just made don't cut it. Here’s what I did to help to me select/set some variables before going into the game.

We can reuse the DirectMatchEntryStatic class we have created previously:

1. We can add some variables here so that other classes will be able to access it.

2. Using the static variables, we can force certain scenes to be loaded

3. Repeat step 2 for character selection and AI Selection

This implementation allows developers to test features with greater control.

Conclusion

There are so many more tools I can share, but I have chosen these two specifically as I use them the most in my day-to-day at Mighty Bear Games. This has helped me a lot during the development cycle, and without these tools, my assigned features would definitely have taken much longer to be implemented.

Hopefully, my short introduction to these tools has given you some kind of idea on what you can implement in your project to help you! If you enjoyed this article, drop me some claps, leave a comment, and follow the Mighty Bear Games publication on Medium.