How to write automated tests for your consent banner

Consent banners break silently. A deploy reorders scripts, a new tag fires early, a framework upgrade changes load timing, and nobody notices for weeks because the banner still looks fine. Automated tests catch that drift in CI. Here are the five behaviors worth testing.

Test that nothing fires before a choice

Load the page in a fresh browser context with no stored consent, intercept all network requests, and assert that no analytics or marketing hosts are contacted before the visitor interacts with the banner. This is the single most valuable test: it catches the entire class of trackers-firing-before-consent bugs.

Be strict about the host list. Maintain an explicit allowlist of strictly necessary requests and fail the test on anything else. A test that only checks for known-bad hosts will miss the new tracker nobody has heard of yet.

Test the accept and reject paths separately

Accept path: click accept, assert the consent state is stored, then assert the expected analytics and marketing tags fire. Reject path, in a fresh context: click reject, assert the consent state records the refusal, and assert no non-essential requests fire afterward.

Also test the preferences panel directly: open it, toggle individual categories, save, and assert the stored state matches the toggles. The panel is where most consent APIs have their subtlest bugs.

Test persistence and changing your mind

Accept, navigate to another page, reload, and assert the banner does not reappear and the stored choice is intact. Then revoke consent through the preferences link and assert the tags stop firing. Regulators care about withdrawal being as easy as consent, and this test proves it works.

Keep the suite fast and deterministic

Run the tests against a fixed build with network stubbing for third-party hosts so the suite does not depend on the analytics vendor being reachable. Flaky consent tests get disabled, and a disabled consent test is the same as no test.

Run it on every deploy

Consent is a regression surface like any other. Add the suite to the pipeline that ships the site, and block the deploy when it fails. The first time it catches a marketing tag added through the tag manager without a consent update, it pays for itself.

What a minimal consent test looks like

A typical test opens the site in a fresh browser context, waits for the banner, and collects every network request made before any interaction. It then asserts that none of those requests went to analytics or marketing hosts. That is the whole first test, and it catches the most common failure mode.

The second test clicks accept and asserts that the consent state object contains the accepted categories and that the expected tags subsequently fire. The third test starts fresh, clicks reject, and asserts the opposite. Three tests, each under twenty lines, cover the behavior regulators actually check.

Testing the consent API surface directly

Beyond the banner UI, test the API your application code calls: the function that reads the current consent state, the event that fires when consent changes, and the queue that holds tags until consent arrives. Unit-test these in isolation with mocked states for accept, reject, and partial consent.

The partial-consent case deserves its own attention. Most consent bugs live there: analytics accepted but marketing rejected, or consent given on one subdomain and read on another. If your API handles partial states correctly, the banner UI problems become cosmetic rather than structural.

Document what each test protects

Every consent test should have a one-line comment naming the regulation or incident it guards against: prior consent before tracking, withdrawal as easy as consent, state surviving navigation. When a future developer is tempted to delete a failing test to ship faster, that comment is what makes them fix the code instead.