Playwright for testing responsive designed websites - Mobile First
Introduction
The percentage of global web traffic on mobile phones has surged over the past decade. In August 2023, 55.5% of all web traffic came through mobile phones, with the average for 2023 so far coming in at 56.69%.?
This trend (of increasing mobile users) is reflected in my own test automation experience over the last 5 years. In particular, for the past year I have been implementing a Playwright? based test automation framework where the main web application is predominantly accessed by mobile users.?
Whilst Playwright cannot test native mobile applications and its ability to test mobile browsers on real and emulated devices is currently (12/2023)? limited to an experimental feature for Android, I believe (given its utilization of the Chrome DevTools Protocol - CDP)? it offers a compelling framework as a part of a wider robust? architecture for testing within a Mobile First Design strategy.
The following article documents the challenges of testing within a Mobile First Design strategy and Playwright’s ability to meet those challenges.
Mobile First Design is a design philosophy and strategy that involves prioritizing the design and development of a website for mobile devices before considering larger screens, such as desktops or tablets. In essence, it involves starting the design process with a focus on the constraints and opportunities presented by mobile platforms and progressively enhancing the experience for larger screens. It is important to note that this approach applies to browser based applications (not native Apps which are outside the scope of this article).
Key principles and characteristics of Mobile First Design include:
The mobile-first design philosophy has become increasingly important with the widespread use of smartphones and tablets. It ensures that websites and applications are not just scaled-down versions of their desktop counterparts but are purposefully crafted to meet the specific requirements and preferences of users on mobile devices. Additionally, it aligns well with the idea that mobile usage is often the first point of contact for many users.
The challenges of testing a progressive Mobile First Design
Testing within a Mobile First Design approach presents specific challenges that need to be addressed to ensure the optimal functionality, usability, and performance of mobile websites. Here are some of the key challenges associated with testing in a Mobile First Design context:
This list of challenges will be used later to evaluate Playwright features as to the extent to which those features address the challenges of testing within a Mobile First Design approach.
Playwright's features that address the challenges of testing within a Mobile First Design Approach
Playwright came into existence in January 2020, partially in response to providing an alternative to the Selenium (WebdriverIO) framework which has been a leading solution in web automated testing since 2004. What Playwright (and other recent web testing frameworks, notably Puppeteer and Cypress) bring is the ability to determine the state of the DOM prior to executing a step that requires it to be in a given state and then providing status feedback (two way communication) to the tests. With Selenium there is a connection termination after every request which results in slower execution and a layer of timing flakiness, mitigated be a collection of waits (implicit and explicit) in the tests themselves.
Sidebar - Selenium something to watch: As of today (12/2023) Selenium is in the process of implementing the BiDi (Bi-directional) protocol, which will narrow the gap, in terms of action timing challenges on the DOM, between it and other modern browser testing frameworks such as Cypress/Playwright/Puppeteer.
Behind the scenes Playwright uses ?Chrome DevTools Protocol (CDP) to control the interaction with the browser (similar to Puppeteer, from which Playwright was derived). It is Playwright’s use of CDP that has an additional benefit (apart from driving the browser interaction) of utilizing the Chrome DevTools features to emulate various browser host devices (including mobile) and to analyze web page performance.
Playwright has two mechanisms to emulate web browser host devices, including mobile:
领英推荐
Playwright’s configurable Device Emulations
Playwright comes with a registry of device parameters using playwright.devices for selected desktop, tablet and mobile devices. It can be used to simulate browser behavior for a specific device such as user agent, screen size, viewport and if it has touch enabled. All tests will run with the specified device parameters.
"iPhone 6 Plus": {
"userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/17.4 Mobile/15A372 Safari/604.1",
"viewport": {
"width": 414,
"height": 736
},
"deviceScaleFactor": 3,
"isMobile": true,
"hasTouch": true,
"defaultBrowserType": "webkit"
}
Which can then be included in a Project config as variable? e.g. ‘Mobile Safari’ , within playwright.config.ts (js).?
export default defineConfig({
projects: [
{
name: 'Mobile Safari',
use: {
...devices['iPhone 6 Plus'],
},
Note: there can be multiple ‘Project’ definitions configured and one or more can be selected for use during a test run, with or without parallelization.
In the above device configuration viewport will restrict the screen size to that of the iPhone 6 Plus and as the test executes it will verify that the elements are visible (could be scrolled) and actionable.
This restriction of the Viewport will verify the two basic mechanisms used in responsive design implementations:-
CSS Media Queries: Various responsive CSS Queries that add and remove DOM elements using CSS (example: the Hamburger mobile menu CSS below) and allow for conditional logic (based on mobile flag(s)) to be included in the Playwright tests.
CSS Media Query example followed by sample Playwright test
/* Styles for larger screens */
nav {
/* Your regular navigation styles for larger screens */
}
/* Styles for smaller screens (e.g., mobile) */
@media only screen and (max-width: 768px) {
/* Hide the regular navigation */
nav {
display: none;
}
/* Show the hamburger menu button */
.menu-button {
display: block; /* Display the hamburger menu button */
/* Add styling for the hamburger icon, such as background, padding, etc. */
}
/* Styles for the navigation when the hamburger menu is open */
nav.open {
display: block; /* Display the navigation when the menu is open */
/* Add styling for the open navigation, such as background, padding, etc. */
}
}
if (isMobileView) {
// Interact with the mobile menu
await page.click('.menu-button'); // Adjust the selector for your menu button
// Other interactions with mobile menu items
} else {
// Interact with the regular menu for non-mobile view
await page.click('.regular-menu-item'); // Adjust the selector for your regular menu item
// Other interactions with regular menu items
}
Responsive designs that do not add remove DOM elements (i.e. do not use CSS media queries), include CSS Grid, Flex box, and relative units like percentages can use the same locators and actions regardless of the Viewport restrictions. Playwright will ensure that the elements are visible and actionable whilst simulating any Viewport.
Playwright’s access to the underlying CDPSession
Playwright allows raw access to the underlying CDPSession API which in turn allows for additional mobile emulation parameters (such as CPU Throttling and Network emulation) as well as web page performance analysis.?
The following code snippet gives an idea of how to access the Emulate, Network and Performance domains of a CDPSession using Playwright.
const session = await page.context().newCDPSession(page)
/* Use the CDP Sesssion Emulate Domain to Throttle the CPU - Throttling rate as a slowdown factor (1 is no throttle, 2 is 2x slowdown, etc).
*/
await session.send('Emulation.setCPUThrottlingRate', { rate: 1 })
/*
Use the CDP Network Domain to emulate the Network Conditions
offline: boolean - True to emulate internet disconnection.
downloadThroughput: number - Maximal aggregated download throughput (bytes/sec). -1 disables download throttling.
uploadThroughput: number - Maximal aggregated upload throughput (bytes/sec). -1 disables upload throttling.
latency: number - Minimum latency from request sent to response headers received (ms).
*/
await session.send('Network.enable')
await session.send('Network.emulateNetworkConditions', {
'offline': false,
'downloadThroughput': 200 * 1024 / 8,
'uploadThroughput': 200 * 1024 / 8,
'latency': 20
})
// Enable the CDPSession to record performance metrics.
await session.send("Performance.enable");
// Interact with the Playwright CDP Session enabled page
await page.getByRole("button", { name: "Submit" }).click();
// ....
// After the playwright interaction, review the performance metrics
console.log("=============CDP Performance Metrics===============")
let performanceMetrics = await session.send("Performance.getMetrics")
console.log(performanceMetrics.metrics);
CDPSession's capabilities for performance analysis are evolving and the above code only gives a hint of it's usage within Playwright. The following resource gives a more in-depth insight into Playwright and CDPSession's utility for web Page Performance analysis, which can be coupled with Playwrights Mobile Device emulation to estimate performance on various devices as part of an ongoing progressive Mobile First Design strategy.
Concluding remarks
In terms of utility and ease of use (in quickly developing and evolving non-flakey automated web browser tests) with mobile emulation, Playwright offers a robust framework for testing within a progressive Mobile First Design strategy.?
Playwright’s limitation is that it can only target browsers that support CDP, which includes Chromium, Chrome and Microsoft Edge (in addition to the Webkit browser engine and a custom version of Firefox).
Whether or not Playwright is the right framework for any given environment depends on multiple factors, including the variation in the code (javascript) behavior on various platforms as well as the consequences of a failure in production due to those code portability issues. In any event, strategic manual testing on real devices should always be used to mitigate any portability risks of failure.