Why Automate Consent Testing

Manual consent checks are easy to skip and easy to get wrong. A new tag added by marketing, a theme update or a refactored script loader can quietly start firing trackers before consent, and nobody notices until a customer or regulator does. Automated browser tests turn the question “does our banner still behave?” into something that runs on every release. Playwright is a good fit because it controls real browsers, can intercept network requests and gives you fresh, isolated browser contexts.

The Test Contexts

Each test should start from a clean browser context, with no cookies and no local storage. That mimics a first-time visitor. Create a new context per test rather than reusing a page, otherwise a choice stored by one test leaks into the next.

Test 1: Nothing Fires Before Consent

Listen to every network request from the moment the page starts loading. Load the page, wait until it is idle and do not touch the banner. Then compare the requests against a list of tracker domains you maintain, such as analytics, advertising and social pixels. The test fails if any request goes to a listed domain. Also read the cookie list from the context and fail if any non-essential cookie exists.

Test 2: Reject Keeps Things Off

1. Load the page in a fresh context.
2. Click the reject control in the banner.
3. Navigate to two or three further pages, including one with embedded media.
4. Assert that no tracker requests were made and no non-essential cookies were set.
5. Reload and assert that the banner stays hidden and the choice persists.

Test 3: Accept Enables What It Should

Click accept and assert that the expected tags now fire, for example your analytics request. This guards the opposite failure: a banner that records consent but never releases the scripts, which silently costs you data and revenue.

Test 4: Granular Choices

Open the preferences layer, enable one purpose only and save. Assert that tags tied to that purpose fire and tags tied to the others do not. Keep a small mapping file from purpose to expected domains so the test reads clearly and is easy to update.

Test 5: Withdrawal

Accept, then reopen the settings through your persistent link and withdraw. Assert that subsequent requests to trackers stop and that the stored consent state reflects the change. Note that cookies already set may need to be removed explicitly, so decide what your policy is and test for it.

Test 6: Signals

If you use Google Consent Mode, read the data layer in the page context before and after each choice and assert that the consent state values match: denied by default, granted for the categories the visitor accepted. If you use a TCF string, read it through the TCF API and assert that it is present after a choice and reflects it.

Keeping Tests Reliable

• Use stable selectors, such as test attributes or accessible roles, instead of CSS classes that change with design updates.
• Wait for explicit conditions, not fixed delays.
• Run tests against a staging copy that has the same tag setup as production.
• Run a small version of the suite on a schedule, not only on deployments, because third-party scripts change without your release.
• Test the main regions you serve by setting geolocation or using the region override your CMP offers.

How FlexyConsent Fits

FlexyConsent supports IAB TCF 2.4, IAB GPP v1.1 and Google Consent Mode v2, so the signals you assert on in the tests are standard ones you can read from the page. The banner is available in 58 languages; if you serve several, include a test that loads at least one non-English version.

Key Takeaways

• Use a fresh browser context per test to simulate a first-time visitor.
• Assert on network requests and cookies, not just on what the banner looks like.
• Cover four paths: no interaction, reject, accept, and withdrawal.
• Check consent signals in the data layer or TCF API as well.
• Run the suite on release and on a schedule to catch drift from third-party scripts.