Verdict
Yes
Yes, automated UI testing is worth it for the flows customers cannot work without: write one browser test per flow that finds elements by role and label, run it on every pull request, and unit test the logic behind the screens.
Why
- Blast radiususers
- Change frequencyregularly
- Detectabilitysame-day
- Reversibilitywith-effort
- Test costmoderate
Yes, automate UI tests for the few flows customers cannot work without, and test the logic behind the screens below the UI. My typical case is a customer-facing web app. Blast radius is users, because a dead screen stops customers from working, and Change frequency is regularly, because most monthly features change a screen. Detectability is same-day, because a customer who cannot finish a flow writes to support, and Reversibility is with-effort: a hotfix plus replies to tickets. Test cost is moderate, because a test that finds elements by role and label takes about an hour and survives a restyle, so rule R12 gives Test minimally; tests that break on every layout change raise Test cost to heavy, and the decision becomes Do not test.
| When | Decision | Why |
|---|---|---|
| The screen places an order that charges the customer's saved card | Test mandatory: a UI test of the order flow in the payment provider's test mode, plus unit tests for every amount | Blast radius rises to money and Reversibility to costly, because a double charge needs a refund |
| A form shows a saved message while a broken field binding sends an empty value that the server accepts | Test: a UI test for each form that saves data, which reopens the form and checks every field | Detectability moves to eventually, because the saved record looks complete |
| The screen sends an email to a customer segment that the user picks | Test: a UI test that picks a segment and checks the recipient count on the confirmation step | Reversibility rises to impossible and Detectability moves to eventually: a sent email stays sent, and a wrong audience raises no error |
| The app is a desktop GUI whose only automation needs a live desktop session and breaks when a control moves | Do not automate the GUI; unit test the view models and click through the main screens before each release | Test cost rises to heavy, while Detectability stays same-day |
| The app is an internal admin tool whose screens change a few times a year | Do not write UI tests; click through the changed screen after each release | Blast radius falls to internal and Change frequency to rarely |
What breaks if you don't test
Unit tests and API tests stop below the screen, so they stay green when the screen is wired wrong. A submit button stays disabled because a validation flag never clears, or a click handler calls a removed endpoint. Customers hit the broken screen after the release, and the first ticket arrives within a day.
What you lose if you over-test
A browser test of one screen takes about eight seconds in my suites, while a Vitest unit test of the rule behind it takes under 10 milliseconds, so a UI test per validation message slows every run. Tests that locate elements by CSS class or XPath fail when a designer renames a class, and the team starts repairing selectors instead of shipping features.
How to test
- Write one Playwright or Cypress test per main flow, and run it on every pull request against the app with seeded data.
- Find elements by role and label, as the Playwright locator guide and the Testing Library query priority recommend.
- Move validation and state rules out of the view into plain functions or a Presentation Model, and unit test them there.
- When a UI bug reaches customers, add one UI test that reproduces it.
When the answer changes
- The screen charges a card or sends messages that you cannot take back.
- The only automation that can drive your UI needs a live desktop session.
- The screens are internal and change a few times a year.
Cost estimate
What ten UI tests cost against the failures they catch
The hours come from my own projects; replace them with yours.
- Writing: 10 flows at about an hour per test, the definition of Test cost moderate, is 10 hours.
- Upkeep: each monthly release changes about two flows, and updating one test takes me 30 minutes, so 2 × 12 × 0.5 = 12 hours a year.
- Failures without the tests: before my last two teams had UI tests, a release broke a main flow about once a quarter, and each break cost about 6 hours of finding the cause, hotfixing and answering support. That is 24 hours a year, plus four days on which some customers could not work.
Year one puts 22 hours of tests against 24 hours of failures and four bad days for customers: a slightly positive balance, which is what Test minimally means. Four failures a year never repay a suite of 400 UI tests, which takes 400 hours to write.
Sources
Related questions
FAQ
- Is UI testing worth it?
Automated UI testing is worth it for the flows customers cannot work without, one browser test per flow. For the other screens, clicking through the changed screen before release costs less than a test that needs monthly updates.
- Should GUIs have their own automated tests?
A GUI needs its own automated tests for the main flows, because unit tests cannot see a screen that is wired wrong. Keep the logic in unit-tested functions, so the GUI tests stay few and check only the wiring.
- Are automated UI tests too brittle to be worth it?
Automated UI tests are too brittle to pay off when they locate elements by CSS class or XPath, because every layout change breaks them and raises Test cost to heavy. UI tests that find elements by role and label and wait for them instead of a fixed delay survive a restyle.