Slow test suites often hide a layering problem.
Browser tests carry real cost: rendering, navigation, waits, selectors, authentication, and orchestration. That cost makes sense when the test needs the browser. It wastes time when the assertion only checks business logic.
One feature check took 1 minute and 40 seconds because it reached the assertion through a long UI path. After I moved the right assertions into unit and component coverage, the same behavior took about 1 second to verify.
The UI still had coverage. It no longer carried work that belonged lower in the stack.
Project note
Problem: A feature check spent 1 minute 40 seconds driving the UI to verify behavior that did not require the UI.
Action: I moved the business-rule assertions into faster unit and component coverage and left the browser test to cover the visible user path.
Result: The check dropped to about 1 second.
Lesson: Put an assertion at the cheapest layer that still proves the behavior.
Why it matters
UI-heavy suites push teams toward skipped checks, slow pull requests, and manual regression.
A smaller browser layer also makes failures easier to read because each test points closer to the behavior it owns.
What teams should check
Use these checks when a release depends on similar behavior.
- Which assertions require browser behavior?
- Which assertions prove business rules, formatting, calculations, or data mapping?
- Which checks can move to unit, component, API, or data-level coverage?
- Which UI flows repeat setup only to reach a lower-level assertion?
- Do browser failures point to product behavior or page mechanics?