Why Traditional E2E Tests Break (Three Real Scenarios)

Most e2e failures don't come from the happy path. They come from three specific edges.

Scenario 1 — The JavaScript Dialog That Kills the Selector

You write a Playwright test for a "delete item" flow. It passes locally. It passes in CI. Three weeks later, the product team adds a window.confirm("Are you sure?") before the delete fires. Now every test in the suite hangs for 30 seconds and times out, because Playwright's default dialog handler dismisses the dialog and the page is still blocked on the modal.

The Playwright fix is to register a page.on('dialog') listener — but the listener has to be registered before the click that triggers the dialog, and it has to be re-registered for every page instance. Miss one and the suite goes red on that path forever.

Scenario 2 — Staging Passes, Production Fails

Your CI runs headless Chromium against staging. All green. You ship. Production sits behind Cloudflare, and the first real-user flow trips the bot-detection layer. Your synthetics dashboard lights up, but your e2e suite never caught it because staging didn't have the same protection tier.

The root cause is a fingerprint mismatch: headless Chrome leaks navigator.webdriver, a different WebGL vendor string, and a telltale HeadlessChrome user agent. The usual patch is puppeteer-extra-plugin-stealth, plus a pile of manual fingerprint overrides, plus a proxy rotation, plus keeping all of that in sync with Chrome updates. Each one is a minor project on its own.

Scenario 3 — The Login Step You Can't Automate

Your production login requires a captcha on new devices, an OTP from an authenticator app, and sometimes a manual device-trust prompt. None of these can be scripted without either (a) hard-coding bypass endpoints that don't exist in production or (b) injecting a fake session token that doesn't match the real auth path.

Most teams choose option (b) and accept that the login flow itself is untested. That's a quiet decision to let a load-bearing piece of the product exist outside the test suite.

Fix #1 — Auto-Handle JS Dialogs Without Manual Listeners

The Playwright approach looks like this:

``javascript
// Playwright: you have to remember this line on every page
page.on('dialog', async dialog => {
await dialog.accept();
});

await page.goto('https://app.example.com/items/42');
await page.click('button.delete');
// If you forgot the listener above, this line hangs.
`

Browser-act's v1.1.0 release introduced a global dialog-handling behavior. By default, all alert, confirm, and prompt dialogs are auto-dismissed. If you need a test that actually exercises the dialog branch, you flip one flag:

`bash


Default: all dialogs auto-handled, tests never hang

And when you do need to assert against the page state after a dialog is dismissed — not against dialog text itself — use browser-act evaluate to read directly from the DOM or a global variable, skipping brittle selector chains entirely:

`bash
browser-act evaluate "document.querySelector('.item-row').dataset.status"


returns "deleted" once the confirm is accepted and the row is gone

`javascript
const { chromium } = require('playwright-extra');
const stealth = require('puppeteer-extra-plugin-stealth')();
chromium.use(stealth);

const browser = await chromium.launch({
args: [
'--disable-blink-features=AutomationControlled',
'--no-sandbox',
'--disable-web-security',
],
});
const context = await browser.newContext({
userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 ...',
viewport: { width: 1920, height: 1080 },
locale: 'en-US',
timezoneId: 'America/New_York',
// ... eight more overrides
});
`

`bash
browser-act stealth-extract https://app.example.com \
--content-type html \
--proxy http://user:pass@proxy.example.com:8080 \
--output result.html
`

The --content-type flag controls the return format — html for DOM assertions, text for readability checks, json when you're extracting a specific structure. Combined with --timeout and --output, a single stealth-extract call replaces the five-file test scaffold that a traditional Playwright suite needs just to reach the page.

The pattern is the same across all four: instead of retrying in a loop until the CI runner kills the job with no diagnostic, the test stops, hands off, and resumes once the human signal comes back. You configure it in a policies.yaml per suite:

`yaml
policies:
credential-login:
action: human-assist
notify: slack://#qa-handoff
captcha-unsolvable:
action: human-assist
notify: slack://#qa-handoff
max_solver_attempts: 2
payment-confirmation:
action: pause
url_patterns:
- "/checkout/confirm"
- "/payment/"
operation-stuck:
action: stop
max_retries: 3
report: ./artifacts/stuck-state.json
`

In CI, a stuck test posts a Human Assist URL into a Slack channel. A human clicks, signs in once, and the test picks up from the post-login state. The post-auth state is preserved with browser-act session save and rehydrated with --session on every subsequent test run until it expires — one human sign-in covers the next hundred test executions.

`javascript
// e2e/cart-checkout.js
const { runBrowserAct } = require('browser-act');

// Step 4: proceed to payment — policy stops the test here
await session.click('button.checkout');
// payment-confirmation policy matches /checkout/confirm
// Test exits cleanly with state captured.
// No real card is charged in CI.
}
`

Every row on the right is in policies.yaml. The test file just expresses intent.

Week 1 — Replace the dialog hacks. Find every page.on('dialog') in your repo. Replace the ones that just accept/dismiss with a browser-act stealth-extract call in the same step. Keep the ones that actually assert against dialog text as Playwright steps. You'll delete roughly 40% of your dialog boilerplate.

Week 2 — Wrap the bot-wall tests. Identify the 5-10 tests that flake against staging because of bot detection. Change those specific tests to fetch the page via stealth-extract first, then hand the HTML to Cheerio or JSDOM for assertions. Keep everything else as Playwright. For visual regression on those same pages, browser-act screenshot --full-page --output baseline.png captures a deterministic screenshot you can diff; --har on any extract call writes a full HAR file you can replay to verify API contract expectations.

Week 3 — Add policies for your known unautomatable paths. Login with OTP. Payment confirmation. Anywhere your suite currently has a test.skip() because "we can't automate this in CI." Add the matching policy, wire Human Assist to Slack, and those skipped paths come back into coverage.

• Pure unit tests. If the code doesn't touch a browser, Jest or Vitest is faster and simpler. Don't spin up a Chromium instance to test a pure function.
• API contract tests. If you're testing the response shape of POST /api/orders, use Supertest or Postman collections. Browser-act would just add a layer of indirection.
• High-concurrency load tests. For 10,000 virtual users hammering an endpoint, k6 or Locust is the right tool. Browser agents aren't designed to simulate load.
• Tests of non-browser flows. Mobile app e2e, CLI tool e2e, server-to-server integration — all out of scope.

If you're already running Playwright or Cypress in CI and the flakiness tax is eating your team's time, start with the one policy that hurts the most. Most teams start with credential-login because it unlocks the largest chunk of "stuff we stopped testing because we gave up."

• Install: npm install -g browser-act (or brew install browser-act)
• Docs for v1.1.0 policies: browser-act/skills/browser-act
• The one command for the skeptic: browser-act stealth-extract https://your-staging.example.com --output test.html` — run this against any staging URL that currently flakes in CI, and see whether the output matches what Playwright returns. If they differ, the bot wall was lying to your test suite.

The test you stopped writing is the one that would have caught the bug.