DEV Community: Mauro Laurenzi

How to interact with Stripe's iframes using WebdriverIO

Mauro Laurenzi — Sat, 27 Apr 2024 00:52:38 +0000

Many test automation developers will, at some point, come across the challenging task of automating a payment flow for the app that they're testing. This task becomes even more challenging when the integration with the payment services provider in the UI is done via iframes, as commonly happens with Stripe. In this guide, I will try to make the process of interacting with those iframes a little more straightforward using JavaScript and the WebdriverIO framework.

What are iframes?

Inline frames or iframes can be thought of as little windows within a web page. Developers use them to embed one web page inside another, which allows them to display content from an external source within their own website. Stripe makes use of this concept and provides its own web elements, which are used inside iframes.
Now, while this is very handy for web developers as they can integrate different web elements smoothly, it's also tricky for QA engineers to automate tests that involve working with iframes, because of their encapsulated nature. The automation tool that we choose is important because it needs to be able to switch the context to interact with the elements inside the iframe.

Example

We'll use WebdriverIO to automate the flow to add new credit card information to a web app that integrates with Stripe.

1. Obtaining the iframe locator:

We'll have to inspect the input element through the Chrome DevTools and search for the Stripe iframe that contains it. In this case, as we can see, the iframe doesn't have a unique ID, so one way to identify it could be with its title value. The xpath will look like this: 'iframe[title="Secure card payment input frame"]'.

2. Switching the browsing context to the Stripe iframe:
Once we have found the correct locator for pointing out to the desired iframe, we have to switch the context from the parent frame (webpage) to the particular one that we want to interact with, in WebdriverIO this can be done like this:
await browser.switchToFrame(await $('iframe[title="Secure card payment input frame"]'));
Basically, we create an Element object with await $('locator') and pass it as a parameter to the switchToFrame() command.

3. Interacting with the elements inside the iframe:
Now that we have switched the browsing context to the particular iframe, we can perform some actions to the elements inside of it. Like adding the card number:

One possible locator for the Card number input field could be //input[@name="cardnumber"], so we can write something like:
await $('//input[@name="cardnumber"]').setValue(cardNumber);
And the same goes for the rest of the input fields, like the expiration date, CVC and zip code.
It's important to note that if we don't switch the context to the iframe like we did in step 2, this locator //input[@name="cardnumber"] will not be recognized by the test-runner, the only way to access it is by previously switching to the specific iframe context.

4. Switching back to parent frame:
After we have filled all the necessary values for the credit card info, we'll want to click the “Save Payment Method” button, which is outside of the Stripe iframe, so if we try to run something like:
await $('//button[contains(text(),"SAVE PAYMENT METHOD")]').click()
it won't work since we're still inside the Stripe iframe context; we first need to switch back to the parent frame context to interact with the elements of the main webpage. For this we can use the switchToParentFrame() WebdriverIO command:

await browser.switchToParentFrame();
await $('//button[contains(text(),"SAVE PAYMENT METHOD")]').click();

Finally, our method for adding the credit card info will look something like this:

async addNewCreditCard(cardNumber, expirationDate, cvc, zip) {
    await browser.switchToFrame(await $('iframe[title="Secure card payment input frame"]'));
    await $('//input[@name="cardnumber"]').setValue(cardNumber);
    await $('//input[@name="exp-date"]').setValue(expirationDate);
    await $('//input[@name="cvc"]').setValue(cvc);
    await $('//input[@name="zip"]').setValue(zip);
    await browser.switchToParentFrame();
    await $('//button[contains(text(),"SAVE PAYMENT METHOD")]').click();
}

And this is how, using WebdriverIO's switchToFrame() and switchToParentFrame() commands, we can interact with the elements inside Stripe's iframes after correctly identifying all the necessary locators.

How to test Chrome extensions in headless mode with WebdriverIO

Mauro Laurenzi — Thu, 25 Apr 2024 22:48:18 +0000

Hi! In this article I will try to explain, step by step, how we can load an extension in a Google Chrome browser for test automation and then run our tests in headless mode using the WebdriverIO framework.
First, let's understand what headless mode means and why it could be beneficial for running automated tests on a Chrome extension. “Headless mode” refers to executing a test with no graphical user interface (GUI), meaning that the browser works in the background, without displaying any windows or UI elements.

Why would we want to execute tests this way?

The principal reasons are speed, resource efficiency and compatibility.

Speed: Tests running in headless mode tend to be faster because the test-runner doesn’t have to waste time rendering the UI, it only focuses on executing test commands.
Resource efficiency: Given that UI elements don’t need to be rendered, tests running in headless mode tend to use fewer system resources like memory and CPU. This becomes particularly important when running several tests in parallel or on machines with limited resources.
Compatibility: Tests can behave differently in different browsers or environments. Headless mode can help mitigate this by providing a consistent testing environment across different platforms and browsers, since there is no UI rendering involved.

How can we run automated tests in headless mode with a browser extension installed?

Now that we understand the benefits of headless mode for test automation, let’s see how we can implement this approach when testing a Chrome extension with WebdriverIO:

The first thing you will need is the .dist folder containing the extension you want to test. This is a generated folder that normally contains files like a background.js, content.css, content.js, assets; and most importantly, a manifest.json that has all the necessary parameters and values for launching the extension.
Once you obtain the .dist folder, you can manually make sure that it works by opening a new Chrome instance, clicking on Extensions -> Manage Extensions, turning in the Developer mode toggle, clicking Load unpacked and selecting the .dist folder. If the extension loads without any errors, then the .dist folder is ready to be used for test automation.
Go to the WebdriverIO config file from your project and edit the capabilities section to look something like this:

capabilities: [
    {
        maxInstances: 1,
        browserName: "chrome",
        browserVersion: "stable",
        "goog:chromeOptions": {
            args: [
                "--load-extension=path/to/extension",
                "--disable-gpu",
                "--headless=new",
            ],
        },
    },
]

For this to work, it’s important that you use the --headless=new flag instead of the old --headless one. For more information on how the --headless=new command flag supports test automation of Chrome extensions, unlike the old one, refer to this Chrome for Developers article.
It is also important that you use the WDIO ChromeDriver Service version 8 or above for the supported --headless=new command flag.

That 's it! you’re now ready to run your tests in headless mode with your extension installed in your Chrome browser.