Interface

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.

Yes, test accessibility with automated tools, minimally: run one axe scan per main page in CI and one keyboard test per main flow, so a button without a name or a control that Tab cannot reach fails the build.

Yes, test server-rendered views minimally: render each page once in a request test with realistic records and assert the text users need, and write no separate view specs for templates that only print fields.

Yes, give each UI component that has behaviour one unit test of its main interaction, written with Testing Library against what the user sees, and skip components that only lay out their props.

Visual regression testing is not worth it for the pages of a typical web app: check the elements users need with explicit browser assertions, and keep screenshot comparisons for a shared component library.

No, do not write a test for each prop of a component: props that only set content or style need none, because TypeScript checks them and the author sees them on screen, and each prop that changes behaviour, such as a callback or a disabled flag, gets one interaction test.

Do not write automated tests for CSS in a typical web app; lint stylesheets with Stylelint, scope styles to components, and look at each changed screen at a phone width and a desktop width before merging.

No, do not write assertions whose only job is to check static UI copy such as headings and help text; find elements by role and visible name, and test only the text that the code computes from data.

No, do not find buttons, links and form fields by data-testid; find them by role and accessible name, and add a data-testid only to an element that has no role or name to query, such as a chart drawn on a canvas.

Do not run your tests at every screen size; look at each changed screen at a phone width and a desktop width before merging, and track in analytics the share of visits that finish the main action at each screen width.

Watch each browser in production instead of testing every browser and version: record errors and finished main flows per browser, alert when one browser falls below its usual rate, and roll releases out in stages.