# How to write automated tests for your consent banner - CookieBastion Source: https://cookiebastion.com/blog/automated-tests-consent-banner.html [Home](../index.md) / [Blog](index.md) / How to write automated tests for your consent banner Published September 23, 2026 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. ## Related reading [How to block scripts before consent without breaking your site](blocking-scripts-before-consent.md) [What is a consent management API?](what-is-a-consent-management-api.md) [What is a consent string?](https://cookiebastion.com/glossary/consent-string.md) ## Frequently asked questions ### What should automated consent banner tests cover? The four states that matter: no choice yet with non essential tags blocked, acceptance with tags firing only after the choice, rejection with tags staying blocked across pages, and a returning visit where the stored choice is honoured without re asking. Most suites test the banner's appearance and skip the network behaviour, which is where the failures live. ### How do tests handle the consent banner in end to end runs? Set the consent state explicitly at the start of each scenario rather than clicking through the banner in every test. Seed the consent cookie or use the consent tool's test API, then assert behaviour. Keep one dedicated scenario that does click the real banner, so the interaction itself stays covered without slowing the whole suite. ### Why do consent tests pass in staging and fail in production? Because the tag sets differ. Staging containers often lack the marketing tags added directly to production templates, so blocking looks perfect in tests and leaks live. Run the denied state network assertion against a production like container, and rerun it after every container publish, not just at release time. ## Get a free consent audit of your website [Free consent audit](mailto:hello@cookiebastion.com?subject=Free%20consent%20audit%20-%20cookiebastion.com)