Browser testing

Browser tests are the most expensive tests you own — slowest to run, most likely to break for reasons unrelated to your code, hardest to debug. That cost buys one thing nothing else does: proof that the pieces work together in a real browser.

Spend that budget on a small number of journeys that must never break. A large E2E suite is not thorough; it is slow, flaky, and eventually ignored, and an ignored suite provides no safety while still consuming CI time.

Rule of thumb: if a case can be covered below the UI, cover it there. E2E is for the wiring.

1. Choose the journeys

Pick the paths where failure is unacceptable, typically five to fifteen for a whole product: