Automatically Testing GDPR Cookie Consent Banners

1. A brief legal framing

Under the General Data Protection Regulation and Germany's Telecommunications-Digital-Services-Data-Protection Act, non-essential cookies, say for marketing or analytics tracking, may only get set after an active, informed, and freely given consent from the user, where simply continuing to use the site explicitly does not count as valid consent and declining must be just as easy as accepting.

This requirement covers not just the visible setting of a cookie in the narrow sense, but every loading of a script that transmits personal data to a third party, say a Google Analytics snippet, a Facebook pixel, or a retargeting script, which means, technically speaking, it's not the cookie itself but the actual network call of the given tracking script that is the decisive, check-worthy event. This legal framework is deliberately kept brief here and does not replace individual legal advice for the given project, since detail requirements can differ depending on target audience, services used, and the concrete design of the banner.

2. Deliberately simulating different consent states

For full test coverage, it's not enough to check only the acceptance case, since the cases of declining and not yet decided are actually the more critical scenarios from a legal standpoint: in exactly these two states, not a single non-essential tracking script may load, which is why a test should run a dedicated check for each of the three relevant states, acceptance, decline, and no decision.

In practice, the given consent state can usually be set directly through the browser's local storage object or a cookie managed by the consent management tool itself, instead of manually walking through the entire banner click path in every single test, which makes the test both faster and more precisely focused on the actual consent state under test, independent of possible later, purely visual changes to the banner design itself.

test('no tracking script loads without a consent decision', async ({ page }) => {
  const trackingRequests = [];
  page.on('request', (req) => {
    if (req.url().includes('google-analytics.com') || req.url().includes('facebook.com/tr')) {
      trackingRequests.push(req.url());
    }
  });

  await page.goto('/');
  await page.waitForTimeout(2000);
  expect(trackingRequests).toHaveLength(0);
});

test('tracking scripts load only after active acceptance', async ({ page }) => {
  const trackingRequests = [];
  page.on('request', (req) => {
    if (req.url().includes('google-analytics.com')) trackingRequests.push(req.url());
  });

  await page.goto('/');
  expect(trackingRequests).toHaveLength(0);

  await page.click('[data-testid="consent-accept-all"]');
  await page.waitForResponse((res) => res.url().includes('google-analytics.com'));
  expect(trackingRequests.length).toBeGreaterThan(0);
});

3. Decline as its own, equally important test case

The test case for an active decline should check not just that no tracking script loads after clicking decline, but additionally that a tracking script already initiated through accidental preloading, if the application would even technically allow such a thing, gets correctly blocked or subsequently removed, since a tracking call already started but not yet technically completed could otherwise still lead to a full data leak on a late decline.

Equally worth checking is that a made decline actually persists across a repeated page visit, meaning the full consent banner doesn't reappear on every new page load, which would both be disruptive from a user perspective and would indicate a broken, non-persisted storage of the consent decision.

4. Testing the withdrawal of an already given consent

The General Data Protection Regulation requires that withdrawing a once-given consent must be just as easy as giving it in the first place, which is why a complete test case should also check that a subsequent withdrawal via the corresponding settings page actually stops already active tracking scripts, instead of only blocking future cookie issuance while already set tracking cookies keep running unchanged.

This test case is somewhat more technically involved in practice, since it needs to check not just non-loading as with the original decline, but the active termination of an already running state, say by deleting already set tracking cookies or unloading already embedded scripts, which is why a deliberate check of the browser's cookie storage before and after withdrawal makes sense here, rather than relying solely on observed network requests.

5. Embedded third-party content like videos and maps

Besides classic tracking scripts, many Magento stores also contain embedded third-party content like YouTube videos in product descriptions or an embedded map view in the store locator, which can likewise fall under the consent requirement, since merely loading the iframe already establishes a connection to the third party and thereby potentially transmits personal data like the IP address.

For these cases, the test should check that before consent, a placeholder with its own consent button appears instead of the embedded content, and that only a deliberate click on this placeholder, or alternatively a previously given general consent, triggers the actual loading of the embedded iframe, instead of the third-party content loading unconditionally regardless of the consent state.

6. Interplay with the tag manager in Magento

Many Magento projects don't embed tracking scripts directly but through a tag manager like Google Tag Manager, whose container in turn gets controlled by consent triggers, which at first glance simplifies the actual check, since the consent state gets managed centrally in one place, but actually introduces an additional source of error, since a faulty trigger configuration inside the tag manager itself, independent of the actual application code, can lead to premature loading.

An E2E test should therefore deliberately operate at the network level and observe actual, outgoing requests to known tracking domains, instead of relying solely on the tag manager's correct internal configuration, since only the actually observed network request reliably shows what really ends up happening in the user's browser, independent of the internal complexity of the intervening tag manager configuration.

7. Testing granular consent categories individually

A modern consent banner usually distinguishes not just between full acceptance and full decline, but offers individually toggleable categories like functionally necessary, statistics or analytics, and marketing, where each of these categories controls different scripts and cookies and should therefore, from a testing standpoint, also get checked individually, independent of the other categories.

A typical, often overlooked mistake in the practical implementation is a single tracking script wrongly getting tied to several categories at once, so it already loads on acceptance of the functionally necessary category even though it clearly belongs to the marketing category by content. A granular test case that deliberately activates only a single category and deliberately leaves the others deactivated reliably uncovers exactly this kind of miscategorization, while a test only ever distinguishing between accept all and decline all would completely miss the same miscategorization.

8. Testing consent logging and the accountability requirement

The General Data Protection Regulation requires a data controller not just to correctly obtain consent itself, but also to be able to demonstrate it, which is why a complete consent management system typically needs to log every given or declined decision with a timestamp, the banner version used, and the respective chosen categories, so it can actually prove, if challenged by a supervisory authority, that valid consent genuinely existed.

A complementary test case should therefore check that a consent decision actually produces a corresponding, correctly populated log entry, say through a deliberate check of the corresponding API call or database record, since a technically correctly working banner without accompanying logging provides insufficient legal proof in a dispute, even if the visible user behavior looks entirely correct at first glance.

9. Consent test cases at a glance

The table below summarizes the most important consent test cases and their respective check level.

10. Summary

11. FAQ: Cookie Consent Tests: The Essentials at a Glance