Repeated setup can make a suite slow while each individual test looks reasonable.
A login flow that costs 10 or 20 seconds feels small in one test. Across hundreds of checks, it becomes a suite-wide tax.
In one suite, unrelated scenarios logged in through the UI every time. I moved authenticated state into browser setup by injecting cookies and kept direct login coverage as its own focused check.
The suite still tested login. It stopped using login as a tollbooth for every other behavior.
Project note
Problem: Hundreds of tests spent 10-20 seconds each logging in through the UI before reaching unrelated scenarios.
Action: I injected authenticated cookies into the browser context for tests that only needed a logged-in state and kept direct login coverage separate.
Result: The suite removed repeated login overhead from unrelated checks and reduced a major source of runtime and flake.
Lesson: A setup step belongs in every test only when every test needs to verify that setup.
Why it matters
Repeated UI setup adds runtime and creates failure points before the test reaches the behavior under review.
Authentication, redirects, timing, and page state can all create noise in tests that do not care about login.
What teams should check
Use these checks when a release depends on similar behavior.
- Which tests verify login?
- Which tests only need an authenticated state?
- Can setup move through API, cookies, or storage state?
- Does focused login coverage still exist?
- Which shared setup steps cause most of the suite runtime?