Before the era of automation, testing the game was a bit hectic and tiring mechanism. Here’s discussing all the challenges we faced with manual testing and how we levelled up the game with automation.

The Manual Testing Blues

Human Resources Overload: In manual testing, we examined each of the software or application's crucial components. Without the use of any automation software testing technologies, it took a village of humans to carry out test cases and generate reports.
Time-Consuming: Humans may be awesome, but they're not as fast as machines. Manual testing is very slow. The time it took to decide if a test case passed or failed felt like eternity. Time was a luxury we didn't have.
Forgotten Test Cases: We occasionally overlooked checking a few test cases when performing manual testing. Sometimes errors in the application were identified when performing sanity testing on the production system during a release.
Repetitive Rituals: Manual testing was monotonous and repetitive since test cases have to be manually checked on every application release, which may only have minor revisions as major releases of applications are usually not done frequently.

Due to the challenges posed by using manual testing in the Marriage Card Game, we took a leap from manual testing to automated testing.

Hello Automation!

Human Force: Enter automation testing. Suddenly, we needed fewer human testers. Most test cases were now smoothly handled by automation tools.
Speed: Automation tools carried out the specified test cases much faster. What used to take hours was now wrapped up in minutes. Time was back on our side.
Never Forgetting: Automation tools don't have memory lapses. So, there were lesser chance of bugs in the production application.
Play, Replay, Replay: Automation tools could run the same test cases again and again, with precision timing.

In search of the right tool: Maestro

Initially, Maestro was chosen as a mobile user interface automation testing tool to automate the Marriage card game for testing purposes. But, there were several drawbacks to using Maestro as an automation tool.

Some major drawbacks of using Maestro as the automation tool were:

Unable to take screenshots of the target application for monitoring the testing process.
Not able to specify coordinate values corresponding to x-axis and y-axis for specific touch input.
Unable to handle file operations such as uploading a particular file (for example an image file) in the target application for testing purposes.

Finding the right tool: Appium

An open-source automation tool, Appium, uses a webdriver to run scripts and test native, mobile-web, and hybrid applications on Android or iOS. A remote control interface called webdriver made it possible to observe and manage user agents pertaining to web or mobile applications, facilitating the interaction with user interface elements in the application.

Since automation has to be performed on the Marriage Card Game, some configuration was set so that the automation takes place properly. The following parameters were specified as configuration for automation of the Marriage Card Game to take place in Android.

Setting the Stage for Automation

capabilities: [
{
platformName: 'Android',
'appium:deviceName': 'Android',
'appium:platformVersion': '12', // version of Android
'appium:automationName': 'UIAutomator2', // specifies automation driver
'appium:appPackage': 'com.bhoos.marriage',
'appium:appActivity': 'com.bhoos.sdk.MainActivity',
'appium:noReset': false,
}
],
services: [
[
'appium',
{
args: {
address: 'localhost',
port: 4723,
},
logPath: './',
},
],
],
framework: 'mocha' // Javascript test framework

An automation driver (UIAutomator2) was installed through Appium for automating the flow of user interface elements interaction. Mocha is the javascript test framework through which test cases are written so that each test execution corresponds to a particular flow of interaction with user interface elements for testing purposes.

$ appium driver list // view installed appium drivers
$ appium driver install uiautomator2 // install the UIAutomator2 driver

$ appium driver update uiautomator2 // update the UIAutomator2 driver

Before using Mocha we wrote test cases for automation, test ids and accessibility label ids to set for user interface elements in the code base of the target application so that the automation driver can identify those ids during automation. The components in writing test cases for automation through the Mocha framework were:

describe('name for describe block', () => {
it('name of individual test case', () => {
...
});
});

The describe() function in Mocha is used to arrange tests. It accepts a callback function that contains it() tests as well as a string to explain the collection of tests. In order to mimic the structure of the code being tested, calls to describe() are frequently nested. Individual tests ran using the it() function. It accepts a callback function and a string to describe the test. The describe() blocks frequently contain calls to it().

await $("~accessibilityLabel").click();

await $(`//*[@resource-id="testID"]`).click();

In a test file, the function click() is used to provide tap input to a specific user interface element such as buttons based on either accessibility label id or test id. The usage of click() on suitable accessibility label id or test id may cause user interface to refresh and render new contents on completion.

await $("~accessibilityLabel").setValue(val);

await $(`//*[@resource-id="testID"]`).setValue(val);

In a test file, the function setValue() is used to provide text input to a specific user interface element such as text fields based on either accessibility label id or test id. “val” is a placeholder for the text input value which can be supplied to the setValue().

const windowSize = await driver.getWindowSize();

await driver.touchPerform([
{
action: 'press',
options: {
x: windowSize.width / 2 + 300,
y: windowSize.heignt / 2,
},
},
{ action: 'wait', options: { mseconds: 0 } },
{
action: 'moveTo',
options: {
x: windowSize.width / 2 - 300,
y: windowSize.heignt / 2,
},
},
{ action: 'release' },
]);

In the test file, to facilitate scrolling and swiping actions, driver.touchPerform() function was used. For the driver.touchPerform() function to work, coordinates of the screen being used were obtained. One of the ways to obtain the dimensions of the screen in the form of coordinates is to use the driver.getWindowSize() function. Then x and y coordinates of the driver.touchPerform() could be set suitably to perform swipe or scroll actions. The above code snippet shows swipe action from right to left in terms of direction.

Based on the overview of Appium and Mocha framework usage, Marriage card game has been automated for testing purposes. The video of the automation working is displayed as follows:

Here’s a little code snippet for the same:

async function clickSelector(testId) {

try {

await $(`//*[@resource-id="${testId}"]`).waitForExist();

await $(`//*[@resource-id="${testId}"]`).click();

await driver.pause(1000);

} catch (err) {

console.log("Err: clickSelector", err);

}

}

describe("Run for single player mode", () => {

it("Single player mode set options", () => {

await clickSelector("btnSingleplayer");

await clickSelector("btnBoot-10");

await clickSelector("btnChooseBots");

await clickSelector("btnSelectRange-1");

await clickSelector("btnSelectRange-3");

await clickSelector("btnSelectRange-4");

// right to left swipe action

const windowSize = await driver.getWindowSize();

await driver.touchPerform([
{
action: 'press',
options: {
x: windowSize.width / 2 + 300,
y: windowSize.heignt / 2,
},
},
{ action: 'wait', options: { mseconds: 0 } },
{
action: 'moveTo',
options: {
x: windowSize.width / 2 - 300,
y: windowSize.heignt / 2,
},
},
{ action: 'release' },
]);

await clickSelector("btnViewPackages");

await clickSelector("bot-package-0");

await clickSelector("bot-package-1");

await clickSelector("bot-package-2");

await driver.touchPerform([
{
action: 'press',
options: {
x: windowSize.width / 2 + 300,
y: windowSize.heignt / 2,
},
},
{ action: 'wait', options: { mseconds: 0 } },
{
action: 'moveTo',
options: {
x: windowSize.width / 2 - 300,
y: windowSize.heignt / 2,
},
},
{ action: 'release' },
]);

await clickSelector("btnBack");

await clickSelector("btnGameMode");

await clickSelector("btnBack");

await clickSelector("btnPlay");

await driver.pause(8000);

});

});

Since Appium cannot make intelligent decisions in card games for choosing the appropriate card during each gameplay round, the Marriage Card Game game game could not be automated.

Although there are benefits of using automated testing, it comes with several challenges also, which are as follows:

Selection of the right test automation tool: Choosing the right automation tool is quite tough. With so many options, finding "the one" was a challenge.
Great Expectations: Sometimes, we dream big with automation and have unrealistic expectations in test automation.
Automated tests may have to be occasionally rewritten: Whenever there were changes to the code base of a particular software then automated tests have to be rewritten to reflect those changes during automation.
Production of false positives and false negatives: Automation tests can be too optimistic or pessimistic. Automated tests are susceptible to failure even when there is no genuine issue. This could happen if the test is incomplete or does not cover all planned use cases.

Hence, when we are aware of and adequately manage test automation challenges, the use of automated testing in projects has, to some extent, produced enormous benefits. It is crucial to include software quality assurance processes such as manual testing and automated testing into each step of the software development lifecycle for the detection of errors and their rectification, such as with the Marriage Card Game.

Get in Touch

testing