I understand unit testing business logic, and I can also see the value in testing custom, self-contained components such as a data table where the inputs and outputs are easy to control. What about testing the overall UI? Is it useful to test third-party components to confirm that buttons render labels and invoke callbacks, check that pages contain particular buttons or links, or verify that entering login credentials successfully authenticates a user? What kinds of UI tests do you typically write, and where do you draw the line between unit, component, integration, and end-to-end tests?
4 Answers
Use end-to-end tests for a thin set of user-critical flows instead of trying to unit-test every visible element. A browser tool such as Playwright can verify login, checkout, account changes, and other workflows that must not break. These tests can also cover role-based access: log in as different roles and confirm that users can perform the actions they should, while unauthorized actions remain unavailable. I would test permissions at the API as well, since the UI alone is not a security boundary.
The right amount of UI testing depends on what would hurt the product if it broke. I would prioritize custom behavior, complex state and validation logic, important formatting, accessibility, permissions, and a few revenue- or workflow-critical paths. I would skip tests for standard library primitives and trivial button existence checks unless those details represent a meaningful business requirement. The goal is not maximum test count; it is useful confidence without creating a maintenance burden.
That tradeoff matters even more for small teams. A manual walkthrough plus automated checks for the core paths may provide better value than maintaining exhaustive tests for every page and component.
Be cautious with broad snapshot testing. Large DOM snapshots become noisy, and a harmless style change can break dozens of tests without revealing a real defect. If visual appearance matters, reviewed screenshot comparisons can be more useful than raw markup snapshots. Accessibility checks with tools such as Axe are also worthwhile, along with explicit tests for complex semantics, keyboard behavior, and regressions that have previously affected users.
I usually think of UI coverage as a pyramid: unit tests for complicated logic, component tests for behavior in code we own, and a relatively small set of integration or end-to-end tests to confirm that important pages and flows work together. I would not test whether a vendor's button renders its label or calls its callback—that should be covered by the library's own tests. For our components, I focus on state transitions, conditional rendering, calculations, formatting, and behavior that isn't supplied by the browser or a third-party package.
That boundary gets less obvious when a component library is copied into the application and heavily customized. In that case, I treat the modified behavior as our code and test the defaults and the important variants, rather than testing every implementation detail.
Exactly—checking whether a role can actually perform an operation is more important than merely checking whether a button is hidden. The UI assertion is still useful for the user experience, but the server-side authorization check is essential.