Reliably Isolating Third-Party Scripts in Tests

1. Why third-party scripts represent a real test risk

A modern e-commerce frontend typically embeds a whole range of external scripts, say an analytics and tracking script, a payment widget, a chat or support tool, and occasionally additional marketing pixels, each of these scripts coming from its own provider the team doesn't control and consequently carrying its own availability, speed, and change risks.

An E2E test that loads a page with all these embedded scripts unchanged becomes potentially unstable through every single one of them: a slow-loading chat widget delays the full page build, a temporarily unreachable tracking service can in the worst case trigger JavaScript errors, and a changing payment provider selector breaks tests that were actually never meant to check the payment method itself, only the checkout flow before it.

2. Typical symptoms of flaky tests caused by external scripts

A reliable indicator of flakiness caused by third-party scripts is a test that fails with different frequency locally versus in the CI pipeline, without anything having changed in the actual code under test, since external services' reliability can depend heavily on network conditions and time of day, while a local development environment often has a better, more stable connection than a CI runner in a shared data center.

Another frequently overlooked symptom is sporadically appearing, extra network requests in the test log that have nothing substantively to do with the actual test case, yet still unnecessarily extend the test's total runtime, since the browser waits for all embedded resources to finish loading before continuing the test, even when the actually relevant DOM assertion could already be satisfied.

A third, particularly insidious symptom occurs when a third party updates its own script without notice, changing say an internal CSS class or a DOM structure within an embedded widget, causing a test that accidentally also targets elements inside that foreign widget to suddenly fail without any change to the project's own code, which additionally complicates debugging since the cause lies outside the own codebase.

3. Deliberately blocking external scripts via route interception

For third-party scripts whose behavior is irrelevant to the given test, say a pure tracking pixel with no visible UI effect, fully blocking the corresponding network request is the simplest and most reliable solution: the request gets intercepted before it ever reaches the external system, so neither that service's load time nor its potential errors can affect the test.

import { test, expect } from '@playwright/test';

test('checkout flow without external tracking and chat scripts', async ({ page }) => {
  await page.route(/googletagmanager\.com|analytics\.google\.com|chatwidget\.example\.com/, (route) =>
    route.abort()
  );

  await page.goto('/checkout/cart');
  await page.locator('[data-testid="checkout-button"]').click();
  await expect(page.locator('[data-testid="checkout-step"]')).toHaveText('Shipping Method');
});

4. Mocking instead of blocking when the frontend reacts to the script

As soon as the actual frontend code actively reacts to a global object an external script provides, say a dataLayer object for tracking events or a global payment SDK object, fully blocking the script causes that object to never exist, and the frontend code accessing it breaks with a JavaScript error, even though the actual test case doesn't target the external script itself at all, only the correct behavior of the project's own code.

In this case, deliberate mocking is the better choice: instead of blocking the network request, the test injects a minimal, hand-written replacement object with the same method names the project's own frontend code expects before the page loads, letting that code keep working normally while the actual, potentially unstable external script never gets loaded.

test('tracking event fires correctly on add to cart', async ({ page }) => {
  await page.addInitScript(() => {
    window.dataLayer = [];
  });
  await page.route(/googletagmanager\.com/, (route) => route.abort());

  await page.goto('/catalog/product/view/id/123');
  await page.locator('[data-testid="add-to-cart"]').click();

  const events = await page.evaluate(() => window.dataLayer);
  expect(events).toContainEqual(expect.objectContaining({ event: 'add_to_cart' }));
});

5. Deliberately isolating payment widgets: sandbox versus mocking

Payment widgets are a special case, since many payment providers deliberately don't offer a complete mock solution for the actual payment process, offering instead a dedicated sandbox environment that accepts real test card numbers but never triggers an actual charge, which is why a genuine sandbox integration usually suits the central, critical checkout path better than a hand-written mock.

For every test checking the checkout flow up to just before the actual payment page without testing the payment process itself, blocking or mocking the payment widget still makes sense, to avoid unnecessary dependency on an external sandbox system that in turn can bring its own availability and speed fluctuations.

6. Deliberately isolating chat tools and tracking pixels

Chat widgets frequently embed their own, sometimes several-hundred-kilobyte JavaScript bundle and additionally establish their own WebSocket or polling connection to an external support system, making them among the heaviest and most frequently responsible third-party resources for significant delays, even though most E2E tests never actually interact with the chat widget.

For tracking pixels and marketing scripts, typically embedded as a single, small image or small script file, a blanket block of all known tracking domains through a central, project-wide reusable pattern is usually enough, instead of defining a fresh blocklist for every single test.

7. Measuring test speed before and after

The actual speed gain from consistently blocking irrelevant third-party scripts can easily be demonstrated by running the same test suite once with and once without the active blocking rules, where the difference amounts to several seconds per test case in many real projects and adds up to substantial total runtime savings across hundreds of tests in a CI pipeline.

This measurable improvement also provides a strong argument within the team for establishing consistent blocking as a fixed standard for new tests, instead of leaving it up to the individual developer whether a test file invests the extra time to set up blocking rules or not.

8. Testing cookie consent and conditional loading of third-party scripts

In most European online stores, tracking and marketing scripts are legally only allowed to load after a user has actively consented to cookie usage, which is why a deliberate test should check that not a single network request to a known tracking domain gets sent before that consent, while the corresponding scripts reliably get loaded afterward once consent has been simulated in the consent banner.

Since practically every E2E test hits the cookie consent banner with a fresh browser context, it pays off to define dismissing or deliberately rejecting that banner as a central, reusable setup step that runs automatically before every actual test case, instead of writing duplicated code for the same banner over and over in every single test file.

9. Practical Magento and Hyva context

In a typical Magento store with a Hyva frontend, Google Tag Manager, a payment provider SDK from a common payment service provider, and a chat or review widget are among the most commonly embedded third-party resources, which should be consistently blocked or mocked in the large majority of frontend tests that don't explicitly check tracking, payment, or chat themselves.

The table below summarizes the isolation strategies presented for third-party scripts.

10. Summary

11. FAQ: Third-Party Isolation: The Essentials at a Glance