Testing what matters

A test suite is worth what it catches. Both too few tests and too many produce the same result: nobody trusts them.

Test behavior, not implementation. A test that asserts a component renders a particular class name fails whenever the styling changes, and passes when the feature breaks. A test that asserts the user sees the error message after a failed submission keeps its value across a rewrite. The question to ask is: if this test fails, has something the user cares about actually broken?

Find elements the way a user finds them. By label, by role, by visible text. Selecting by CSS class or test id ties the test to the markup and hides the fact that a control may have become unreachable for a screen reader. If a test cannot find a button by its accessible name, that is a finding, not an inconvenience.

A test with no failing case is decoration. Before writing an assertion, know what would make it fail. A test that passes against a deliberately broken implementation proves nothing, and this is worth checking directly: break the code on purpose and confirm the test notices.

Mock at the boundary, not in the middle. Replacing the network is reasonable. Replacing your own functions with mocks means the test verifies the mocks. Where you mock a response, make it the shape the real server sends, including the failure shapes.

Test the cases that are hard to reach by hand. Empty results, a failing request, a slow response, a rejected permission. Those are the paths a manual check skips, which makes them the ones a test is most useful for.