Unleashing the Power of Playwright in Mobile Automation Testing

Published in

Innovies Club

7 min readFeb 8, 2023

In this article, we will not be discussing the comparison or capabilities of the mighty Playwright vs other frameworks, as there are already many resources available on the topic. Instead, We will concentrate on highlighting the capability of the Playwright and demonstrate how it can be used to construct a clean and efficient, sturdy mobile automation framework.

Join us as we dive into the world of Mobile automation testing with Playwright.

Real device/Emulator for testing

Using an emulator is an essential part of the app development process. It allows QA engineer to test their applications in a simulated environment that is similar to the user experience, providing more accurate results than testing on a desktop browser alone. Testing on a desktop browser with different viewports can provide some insight into screen responsiveness, but it cannot fully replicate the real device or emulator experience. This is because the emulator mimics the hardware and mobile architecture of a device, which affects how the app is rendered and displayed.

Playwright

An open-source, automation testing framework that operates independently of Selenium. It boasts a unique architecture that relies on a client-server model, where the client library communicates with a locally-running browser process. The DevTools Protocol is employed for direct interaction with the browser, facilitating quick execution and support for multiple browser execution. This architecture sets Playwright apart from other testing frameworks and enables advanced functionality.

Why playwright?

Playwright offers a unique advantage in mobile automation testing as it eliminates the need for any additional drivers or proxies to communicate with real devices or emulators. This means that the tests can run directly on the target device, without any intermediary software. This greatly improves the speed and reliability of the testing process, as there is no added latency or potential for miscommunication between the testing tool and the device.

Furthermore, the absence of additional drivers makes the testing process much more streamlined, saving time and resources. This makes Playwright a valuable tool for mobile automation testing, providing efficient and accurate results.

Although this feature is still experimental, the potential for creating efficient and neat custom automation solutions is immense, taking mobile automation testing to new heights.

Prerequisites

The Android SDK must be installed and the path variable must be configured.
An Android emulator must be set up or a real device.
The Playwright template must be prepared and ready to use. check here

Getting started

It should be noted that testing against an Android emulator is still in its experimental stage. The code snippets provided by the official documentation may not be the best option for building a custom automation framework that is extendable, reusable, and reliable.

If you want to fully leverage the capabilities of playwright, it is recommended to develop a customized framework. Let’s get started and make it happen.

Code snippet for playwright's official document

After installing the Playwright ts template, I edited the configuration file and removed several properties as they pertained to desktop browsers and had no impact on the Android device. As a result, it’s not possible to generate screenshots and trace folders through Playwright’s configuration.

Going forward with our implementation, we need to make the framework easily extendable and reusable, without having to repeatedly copy chunks of code for each test. We aim to make it minimal and straightforward to understand.
To achieve our goal of making a neat framework, we need to comprehend the test execution workflow. This involves launching the server with the necessary information for the desired device, obtaining the wsEndpoint, launching the Android browser after connecting to the device through that endpoint, creating the web context, and finally creating a new page instance as shown below.

To optimize the use of this code snippet, I created a custom fixture that overrides the initial page context and passes it to the test instance. Additionally, I passed the baseURL in the browser context to utilize the baseURL defined in the Playwright configuration file.

Time now to write some page objects where we are defining our elements and deriving our test steps. We have created a page constructor which is the page instance created as a fixture in the previous step.

In a similar manner, we will create another fixture for the page object (LandingPage class) to improve re-usability and eliminate the need for writing abstraction in our test cases.

Let’s write our test cases using the “fixtures” with “test” annotation, passing “page” and “landingPage” as parameters. The “page” is an isolated [Page] instance created for each test, and fixtures ensure isolation between tests by using context isolation.

Finally, launch the emulator, and don’t forget to connect to the ADB server by running “$ adb devices”. This is a crucial step as it allows Playwright to connect to the ADB server via TCP protocol and access the desired emulator or real device. Without it, communication will fail.

To optimize and reduce manual intervention, we can add a command to automatically launch the ADB server before executing the test, eliminating the need to manually run “$ adb devices”.

Test execution

Performance overview

Although the three tests were functioning as expected, the first one failed for debugging purposes and the others passed. However, I noticed a few points that we need to address.

Pop-up issue

When running the browser for the first time, an Android pop-up will always appear. Although it won’t affect our test as it operates in a different context of the Android system and not within the HTML dome, it’s not aesthetically pleasing to have it displayed.
This issue can be easily addressed by passing a key event “4”, which represents the back button through an ADB shell command. This key event will be integrated as part of our fixtures.

Browser tabs accumulating

As evidenced in the screenshots, tabs are accumulating as the page instances are not automatically terminated, causing a negative impact on Android performance due to increased RAM consumption. To improve performance, it’s advisable to clear the browser cache to return it to its initial state.
To address these two issues, I have updated the fixture as follows:

In the page fixture, I have added two shell commands. The first one will force stop the Chrome browser in case of any running activity, and then clear its cache in preparation for the test. I have also added another fixture using the Automatic fixture technique to run “input keyevent 4” before each test to eliminate the pop-up. I have also created another fixture to run after each test to close the page instance, as shown below:

The beforeEach and afterEach methods can be combined into a single function utilizing the automatic fixture feature, however, I have decided to keep them separate for better understanding. Furthermore, these methods can be named whatever is desired as they are not related to testing hooks.

Screenshot & trace attachments

This is a crucial issue as missing the attachments (screenshot and trace folder) will make it difficult to debug effectively. However, no need to worry, we will manage it.

To capture screenshots of failed test cases, a condition should be added in which, in case of a failed test status, a screenshot of the current state should be taken and pushed to the outputDir, which is ./test-results by default. This can be achieved by utilizing the testInfo parameter and it’s clear that this will be managed within the afterEach fixture.
Resolving missing trace archives is similar to solving missing screenshots, except that we must instruct Playwright to start recording before the test. Based on the test status, we will decide whether to stop recording and push it to the outputDir or simply discard it. Like with missing screenshots, this will also be managed within the afterEach fixture.

With the solutions in place, all our problems should be resolved and we can now give it a try. I will leave the link for the GitHub repository down below 👇🏽.

Re-Run the test 🎉

Test execution after applying the new changes

Checking the report 👏

Playwright report after resolving the attachments issue

Wow, Seems that we have successfully created a top-notch, efficient, and robust mobile automation framework using Playwright 🚀.
Get ready for Part 2, coming soon!

Links

https://github.com/amrsa1/playwright-android
https://playwright.dev/docs/api/class-android
https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_TAB

Thank you for stopping by and reading my blog, hope it was useful & stay tuned for the new upcoming interesting blogs…