When setting up tests that involve touch input (such as with mobile devices), there are some important details to make note of regarding both GameDriver and Unity that will ensure your tests function effectively.


The most important detail to note is that GDIO function calls, such as Tap and/or TapObject, simulate a touch event and therefore will only trigger events that are set up to respond specifically to touch input. However, simulated tap input is not processed when running a game in the Unity editor, even if the relevant events are set up to respond to touch events, effectively limiting Tap and TapObject calls to tests that are being run against a standalone mobile build. Fortunately, there are some solutions to this limitation, depending on the input environment you are working with.


When testing against a project that uses the Legacy Input System, you can take advantage of the fact that Unity by default translates taps to mouse clicks (which can be toggled by setting the static boolean variable Input.simulateMouseWithTouches accordingly). In this case, we can treat taps the same as clicks, and as long as your events are set up to be triggered by clicks, Click and/or ClickObject can be used in place of their Tap equivalents in order to achieve the same results across both editor and standalone mobile testing.


If, however, you are testing against a New Input project or the above solution is otherwise nonviable, similar results can be achieved through a dynamic solution to input testing. Below is a portion of example code demonstrating a dynamic GDIO test:

if (testMode == "IDE")
{
    api.ClickObject(MouseButtons.LEFT, "//*[@name='StartButton']", 30);
}
else api.TapObject("//*[@name='StartButton']", 1, 5);
api.Wait(3000);

As shown above, depending on a stored state representing the current environment we are testing against (in this case represented as a string called testMode), such as IDE or standalone, we can determine whether to make a Click/ClickObject call, or the equivalent Tap/TapObject call.