What UI behavior is actually worth testing?
Asked by
MellowCedar42
I understand unit testing business logic, since it covers code we wrote ourselves. Testing a custom, self-contained component—such as a data table—also seems worthwhile because its behavior is unique and its inputs and outputs are easy to control. But how far should testing go for the overall UI? Should we test third-party components to make sure buttons render labels and invoke callbacks? Should we verify that pages contain particular buttons and links? Should logging in with valid credentials be tested as a UI flow? What other kinds of UI tests provide meaningful value, and which ones are usually just maintenance overhead?
Answers
Use end-to-end tests for the flows users and the business depend on, such as logging in, completing a purchase, or checking role-based access. A tool such as Playwright can verify that different roles see the right controls and cannot perform restricted actions. It is also useful to test the underlying API permissions, since hiding a button in the UI is not a security boundary. Keep these tests focused on critical paths rather than trying to exercise every link on every page.
Reply to this answer
A useful approach is a testing pyramid: unit tests for complicated logic, component tests for behavior you built yourself, and a relatively small set of integration or end-to-end tests to make sure important pages and flows work together. I generally would not test basic behavior of a third-party button—that responsibility belongs to the library. For your own components, test state transitions, conditional rendering, calculations, formatting, accessibility semantics, and regressions that have actually happened.
Reply to this answer
Be cautious with snapshot testing. Large DOM snapshots become noisy when harmless markup or styling changes, and screenshot tests can be more useful when visual appearance genuinely matters. Accessibility checks with tools such as Axe are another worthwhile layer. The key is to test behavior and user-visible outcomes, not implementation details like class names or whether a library primitive happens to render a particular element.
Reply to this answer
The right amount depends on the application and the cost of failure. Test anything that would seriously hurt users or the business if it broke, especially custom workflows, permissions, complex form state, and important integrations. For a small app using standard components, a few manual walkthroughs and a handful of smoke tests may be enough. Writing tests for every third-party control or every button on every page usually creates more maintenance than confidence.
Reply to this answer
Add your answer
Answers are reviewed before publication.
RiverKite83: That role-based approach is really an end-to-end test rather than a unit test, but it is still valuable because it checks the complete user experience.