To test a cookie consent banner, drive three separate journeys (accept all, reject all, and manage preferences), then verify the site does the right thing after each choice: the banner is gone and does not reappear on the next page, the chosen preference is reflected in the UI, and the choice persists across a reload. With BrowserBash you describe each of those journeys in plain English and hand them to an AI agent that opens a real Chrome browser, reads the live banner the way a person would, clicks the matching button, and judges whether the page ended up in the expected state. There are no CSS selectors to pin to the banner markup and no recorded clicks to re-capture when your consent vendor ships a new layout. The honest caveat, which we get to in full later, is that the browser layer proves the UI behaved; it cannot by itself prove that no tracking cookie was actually written, and a good test plan treats those as two different checks.
This guide is narrow on purpose. Plenty of articles cover signup and checkout. Almost none cover the gate that sits in front of every other journey on a site that serves European users, which is exactly the surface most likely to break silently after a vendor update. BrowserBash is a free, open-source CLI from The Testing Academy, and every command below is real and runnable after npm install -g browserbash-cli.
Why the consent banner is the test you keep skipping
The cookie banner is the first thing a real user sees and the last thing most suites test. It is structurally awkward: it overlays the page, it blocks clicks until you deal with it, its markup is usually injected by a third-party script (OneTrust, Cookiebot, Osano, or a homegrown widget) you do not control, and it remembers your decision in a cookie or local storage so it behaves differently on the second visit than the first. Record-and-replay tools hate every one of those properties. A recorded test pins itself to the exact button node the vendor rendered the day you recorded, and the next consent-platform release quietly renames a class or reorders the DOM, so your whole suite goes red at the banner before it reaches the thing you meant to test.
So teams do one of two bad things. They delete the banner with a hard-coded cookie in test setup, so the banner itself is never exercised and a broken Reject button ships unnoticed. Or they leave a brittle click-the-second-button step in front of every test and spend their mornings re-recording it. Neither actually tests consent. Consent is a behavior: did the right thing happen to the page after each of the three choices a user is legally allowed to make?
The choices a consent banner has to honor
A compliant banner under GDPR and the ePrivacy rules has to offer a genuine choice, not just an Accept button. That means your test matrix has at least three rows:
- Accept all. The banner dismisses, non-essential scripts are allowed to run, and the banner stays gone on subsequent pages.
- Reject all. This must be as easy as accepting. The banner dismisses, non-essential scripts stay off, and the site must still work.
- Manage preferences. The user opens a second-layer panel, toggles individual categories (analytics on, marketing off, for example), saves, and the banner records exactly that mix.
Each of those is a UI journey an AI agent can drive end to end. The verification after each choice is where the real value sits, and it is the part record-and-replay tools handle worst.
Dismiss the banner before the main flow
The most common reason an end-to-end test fails on a consent-gated site has nothing to do with the feature under test. The banner overlays the page, intercepts the first click, and the test dies on an unrelated step. The clean fix is to make handling the banner an explicit, intent-level first step, not an afterthought you bolt on with a brittle selector.
Because the BrowserBash agent finds elements through the accessibility tree (roles, accessible names, and states) plus the DOM rather than CSS classes, "click the Accept button" survives a class rename or a DOM reshuffle as long as the button still reads as a button named something like Accept. Here is the banner handled as the opening move of a larger objective:
browserbash run "Go to https://app.example.com. If a cookie consent banner appears, click the button that accepts all cookies. Then verify the banner is dismissed and no consent overlay is covering the page. After that, click 'Sign in' and confirm the login form is visible."
The if a cookie consent banner appears phrasing matters. On a second visit the choice is already remembered and no banner shows, so a step that assumes the banner is always there would fail on a returning session. Describing it as a conditional lets the same objective pass whether the banner is present or not, which is how a person reads the page too.
For a reusable building block, put the consent step in its own markdown test and compose it into other flows with @import. BrowserBash tests are markdown intent files: a # title, numbered or bulleted steps, @import for composition, and {{variables}} whose values are masked in logs. A dismiss_consent_test.md looks like this:
# Dismiss cookie consent
1. Go to {{BASE_URL}}
2. If a cookie consent banner is shown, click the button that accepts all cookies
3. Verify no consent banner or overlay is blocking the page
Any other test then starts with one line:
# Checkout as a guest
@import ./dismiss_consent_test.md
1. Click "Shop now"
2. Add the first product to the cart
3. Go to checkout and verify the order summary shows one item
Now the consent handling lives in exactly one place. If your vendor changes the banner copy from "Accept all" to "Allow all cookies," the agent matches on intent rather than an exact string, so it usually keeps passing without any edit at all. Running either is straightforward:
browserbash testmd run ./dismiss_consent_test.md
browserbash testmd run ./checkout_test.md
Test the three choices and assert what changes
Dismissing the banner so other tests can run is the table-stakes use. The higher-value work is testing the banner itself: that each of the three choices does what it claims. This is where you stop treating the banner as an obstacle and start treating it as a feature with its own acceptance criteria.
Accept all
browserbash run "Go to https://app.example.com. When the cookie banner appears, click the option to accept all cookies. Verify the banner disappears. Then navigate to the pricing page and confirm the banner does not reappear, because the choice should be remembered."
The second half is the assertion that actually has teeth. A banner that dismisses but reappears on every page is a real, reported-by-users bug, and a test that only checks the first dismissal misses it entirely. By navigating onward and asserting the banner stays gone, you verify the choice was persisted, not just visually hidden for one render.
Reject all
browserbash run "Go to https://app.example.com. When the cookie banner appears, click the option to reject all non-essential cookies. Verify the banner closes and the site is still usable: the main navigation works and the homepage content is visible, not blank or broken."
Reject is the choice teams test least and regulators care about most, because a non-functional Reject path (or one buried two clicks deeper than Accept) is the classic dark-pattern failure. The assertion here is deliberately about the site still working after rejection, since the failure mode is a page that breaks when analytics or a third-party widget is denied.
Manage preferences and assert the exact mix
The preference center is the hardest journey because it is a second layer with several toggles, and the agent has to set a specific combination and then confirm it stuck. Natural-language assertions are what make the second part readable; for how that judging works under the hood, see natural-language assertions, how they work.
browserbash run "Go to https://app.example.com. Open the cookie banner's 'Manage preferences' or settings option. Turn analytics cookies ON and marketing cookies OFF, leaving strictly necessary cookies as-is. Save the preferences. Verify the banner closes and a confirmation that preferences were saved is shown."
To prove the mix actually persisted, run a second objective that reopens the preference center and reads the toggles back:
browserbash run "Go to https://app.example.com. Reopen the cookie preferences settings. Verify that analytics cookies are shown as enabled and marketing cookies are shown as disabled, matching what was saved earlier."
If that second run passes, you have evidence the preference center stored exactly the combination the user chose. If it fails because every toggle reset to off, or because saving silently turned marketing back on, you have caught a genuine consent bug, the kind that turns into a regulator complaint rather than a bug ticket.
Assert persistence across a reload
A consent choice that does not survive a page reload is broken, because the whole point of recording the decision is to stop asking. This is its own assertion, and it is easy to express as a journey: make a choice, reload, and verify the banner does not come back.
browserbash run "Go to https://app.example.com and accept all cookies on the consent banner. Reload the page. Verify the cookie banner does NOT appear again after the reload, because the previous choice should be remembered."
This kind of stateful check, where the second visit must behave differently from the first, is exactly the territory where intent-level tests beat recorded clicks. A recording captures the steps of one visit; it has no concept of "this should now behave differently." For the broader pattern of testing the invariant rather than the click sequence, testing user intent, not clicks walks through why that framing holds up better over time.
Why the banner does not trip the agent on late renders
Consent banners are injected by a third-party script that loads after the page, so they appear a beat late. BrowserBash leans on Playwright's built-in auto-wait, with a 15-second ceiling and no manual sleeps, so the agent does not race the banner; it waits for the button to be actionable before clicking. That removes the most common flaky-test cause on consent-gated pages, which is a click firing a half-second before the banner finishes rendering. The deeper mechanics of how the agent copes with elements that appear, move, or re-render are covered in how BrowserBash handles dynamic UIs.
Running consent tests in CI
Consent banners regress most often when a vendor pushes an update you did not schedule, so the highest-value place to run these tests is nightly in CI, not on demand. BrowserBash is built for that. The --agent flag emits NDJSON for machine parsing, --headless runs without a display, and exit codes are unambiguous: 0 pass, 1 fail, 2 error, 3 timeout. A pipeline step is a single command:
browserbash testmd run ./consent_reject_test.md --agent --headless
Add --record and the run captures a .webm video plus screenshots, which is useful when a consent test fails and you want to see whether the banner rendered at all or just had its button renamed. Each run also writes a Result.md you can archive. For pointing the same plain-English tests at a real cross-browser grid, the --provider flag accepts local, cdp, browserbase, lambdatest, or browserstack, and the features page lays out where each provider model fits.
On the model side, the default auto resolution checks Ollama first, then ANTHROPIC_API_KEY, then OPENROUTER_API_KEY, where free models exist. A local model means nothing leaves your machine, which suits consent testing. One honest caveat: very small local models (8B and under) get flaky on long multi-step flows, so for the harder preference-center journeys a 70B-class model (Qwen3 or Llama 3.3) or a hosted model is more reliable.
Honest limits: where this approach struggles
This is the section that matters most, because the gap here is real and worth naming clearly.
The browser proves the UI, not the network. This is the big one. When the agent clicks Reject all and verifies the banner closes and the site still works, it has proven the consent UI behaved. It has not proven that zero non-essential cookies were written, that no tracking pixel fired, or that an analytics SDK did not initialize anyway. Those are storage-and-network facts: verify them with a separate check that inspects document.cookie and the network requests after each choice, or a dedicated consent scanner. A compliant test plan pairs the BrowserBash UI journey (did the banner honor the choice on screen?) with that audit (did the browser actually refrain from setting the declined cookies?). Do not let a green UI checkmark stand in for the network-level proof; they answer different questions. The same split applies to the broader privacy flows in automate account deletion and GDPR flows, where some checks are pure UI and others need a backend or storage check the browser cannot make alone.
Geo-gated and consent-mode variants. Many banners appear only for EU IP addresses, or show a different layout under Google Consent Mode. The agent tests whatever banner the page serves from where the run originates, so if your real users see a banner your CI runner never does, you are testing the wrong variant. Pin the geography deliberately through a provider region or a proxy.
Highly visual dark patterns. The agent reads roles, names, and states well, so it reliably finds Accept and Reject buttons. What it does not judge is whether Reject was made deliberately hard to find through color, contrast, or placement, a design-compliance question a human reviewer or a visual-diff tool answers better.
Non-deterministic phrasing on edge cases. Because the agent decides the next action from the live page, two runs against an unusually ambiguous banner (three near-identical buttons, say) can occasionally differ in which they treat as the primary choice. Tightening the objective ("click the button labeled exactly 'Reject all'") removes most of that, but it is a real trade-off of the intent-first model.
None of these are reasons to skip UI-level consent testing. They are reasons to scope it honestly: BrowserBash gives you fast, low-maintenance coverage of the three consent journeys and their on-screen consequences, and you layer a storage-and-network check on top for the cookie facts the browser cannot see by itself. The full command reference and the markdown-test format live in the learn section.
FAQ
How do I test that a cookie banner reappears correctly for a new visitor but not a returning one?
Run two separate objectives. The first starts from a clean session (a fresh run with no stored consent) and asserts the banner appears, then makes a choice. The second reloads or revisits and asserts the banner does not reappear. Phrasing the appearance check as a conditional ("if a banner appears") keeps the returning-visitor run from failing when the banner is correctly absent, which mirrors how a real returning user experiences the site.
Can BrowserBash verify that rejecting cookies actually blocks the tracking cookies?
Not on its own, and it is important to be clear about that. The agent proves the consent UI behaved (the banner closed, the choice was recorded, the site still works after Reject). Confirming that no non-essential cookie was actually written is a storage-and-network fact: inspect document.cookie and the loaded network requests after the choice, or run a dedicated consent scanner. Pair the BrowserBash UI journey with that storage check for a complete, compliance-grade test.
How do I stop the consent banner from breaking my other end-to-end tests?
Put the consent handling in its own small markdown test (go to the page, accept if a banner shows, verify nothing overlays the page) and pull it into every other flow with @import as the first step. Because the agent matches the Accept control by role and accessible name rather than a CSS class, that one shared step survives most vendor redesigns, so the banner stops being the reason unrelated tests go red.
Does testing consent banners with BrowserBash cost anything?
The CLI is free and open-source under Apache-2.0; install it with npm install -g browserbash-cli. You can run entirely locally with an Ollama model, in which case nothing leaves your machine and there is no per-run cost. If you use a hosted model or a cross-browser provider, those carry their own pricing, but the tool itself does not, and the optional cloud dashboard (via --upload) keeps free runs for 15 days while a local dashboard is available with browserbash dashboard.