Browser tests are worth maintaining when they protect real workflows.
Selenium is a browser automation driver. In Rails apps it is usually used through Capybara system tests, which lets the test read closer to user behavior instead of raw browser commands.
The problem is not browser testing. The problem is letting browser tests become a second implementation of the UI.
A good browser test protects a customer path. A bad browser test protects markup details that change every time the page is cleaned up.
Keep the test surface small.
Browser tests are expensive compared with model, service, or controller tests. Use them where the browser matters: JavaScript behavior, Turbo navigation, forms, authentication, checkout, lead capture, and workflows that combine multiple layers.
- Test the critical path, not every validation branch.
- Prefer stable visible text, labels, and roles over brittle XPath.
- Keep setup local and readable.
- Move business rules into faster tests when the browser is not needed.
Reduce flakiness by removing hidden timing assumptions.
Flaky browser tests often come from waiting for arbitrary time, depending on animations, or asserting before Turbo and JavaScript have finished. Use Capybara's waiting behavior and assert on visible outcomes instead of implementation timing.
Make failures useful.
A browser test should fail with enough context that the team can fix the product or the test quickly. If a failure only says an element was missing, the selector probably knows too much about the page structure and too little about the user's goal.
A practical rule.
If deleting the browser test would make you nervous about a real user workflow, keep it and improve it. If deleting it only removes noise from CI, replace it with a faster test or remove it.
Related insights
