Building a Complete E2E Pipeline for Testing Native Mobile Apps with WebdriverIO

Amr Salem
Innovies Club
Published in
5 min readApr 12, 2023

--

WebdriverIO, Android emulator, GH actions and Appium

Hello again my friend, today I am excited to bring you a new and interesting blog that builds on our previous one. If you haven’t had a chance to read it, you can find it here.

In this article, we will take our automation testing to the next level by running webdriverIO end-to-end tests against an actual Android emulator, all within a single pipeline in a clean and efficient manner. So, let’s get it works.

Objectives

The aim of this blog is to demonstrate how to run mobile automation end-to-end test for native App against an actual Android emulator using Github Actions.

The following key points will be addressed to achieve this goal:

  • Retrieve the previously steps for building an android-emulator
  • Initiate the emulator and confirm that it has booted up successfully.
  • Execute the test
  • Dump the report artifact
  • Visualize allure report

Setting Up workflow

We will simplify the process by replicating the steps that were taken in our previous blog.

Building android emulator

Launch the emulator

In order to initiate the emulator, we must add the shell script that was previously generated in the blog post to our e2e repository. By doing so, the emulator launch process will become simpler and we can verify that the emulator has been properly started before proceeding to the following step.

Launching android emulator
Waiting for emulator to boot up

Installing Appium

To interact with a mobile device, we require the installation of Appium driver along with the UIAutomator2 plugin to provide the necessary APIs.

Installing Appium and UIautomator2

Install dependencies & execute the test

  • In the end, make sure to install the necessary dependencies in your package.json file.
  • Execute the test

Quick tip:

When creating automated tests for mobile applications, it is important to ensure that each test is independent and does not rely on the outcome of any previous test. In order to achieve this, it is recommended to reset the application before or after each test run.

However, there is currently no dedicated command provided by Appium 2 to achieve this. As a result, there is no built-in binding to perform this action using WebDriverIO v8.

Fortunately, WebDriverIO offers a very cool feature that allows you to customize your own commands and use them globally throughout your test suite. With this in mind, I have created a code snippet that utilizes adb shell commands to reset the application.

To complete the process, you will need to call your custom commands in your WebDriverIO configuration file’s before hook to initialize the command before each test run. After that, you can call your new custom command in either the beforeEach or afterEach hook within your test suite, as demonstrated below.

Quick demo for our mobile automation test

I will include the complete repository URL in the links section.

Storing Artifact

I have added Allure into WebdriverIO as a reporter, It will give us a visually appealing reports and facilitating efficient debugging of failed tests.

During this step, we will be generating allure report from Allure results directory then we will store allure-report as artifact this will make it easily and accessible for downloading to our local machines.

Generating allure reports — uploading job artifacts

Visualize Allure report

last but not least, By taking advantage of GitHub Pages, we can leverage its capability to parse our Allure report HTML. This will grant us direct access to our test report upon each run, eliminating the need to download it locally.

In order to achieve this, the first step is to enable Pages for your GitHub repository, followed by the following actions:

  • Setup pages config
  • Upload pages artifacts
  • Deploy Gh-pages

As we now have a duplicated step for uploading artifacts, I have made edits to the workflow to reflect the following changes

Configuring gh-pages, and deploy our artifact

And off course, we must provide the necessary permissions to write to the GH Pages.

Set the required permission

Workflow execution

As shown, our end-to-end test has been executed successfully 🎉.

workflow execution summary
E2e test log

Additionally, it is possible to access our Allure report either by downloading the job artifact or visiting the deployed GH Pages.

Accessing allure report
gh-pages where report has been deployed

By visiting the site, you will be able to access the allure report directly.

Visualizing allure report

Repository Link

https://github.com/amrsa1

https://github.com/amrsa1/wdio-nativeApp

Thank you for taking the time to read my blog — I hope it provided some insight and value into your project. Stay tuned for the new upcoming interesting blogs…

--

--