How do you ensure your test cases stay maintainable as a product evolves?

Test maintenance is where most suites die. The product evolves, the cases don't, the suite drifts into "we run it, but we don't trust it" — and eventually nobody runs it. Practices that prevent this:

Atomic, independent cases. Each case sets up its own preconditions, doesn't depend on another case running first, and verifies one behaviour. Long, multi-step "and then" scripts are unmaintainable — when one step changes, the whole thing has to be rewritten.

Layer abstractions. Common setup (login as a role, create a test order) goes into helpers or fixtures. Tests reference the helper by intent, not by implementation. When the login form changes, you fix one helper, not 200 tests.

Name cases for behaviour, not implementation. "Cart applies the largest applicable discount when multiple coupons are valid" survives a refactor; "test_cart_discount_function_returns_correct_value" doesn't.

Prune ruthlessly. Tests for removed features should be deleted, not commented out. Tests skipped for two sprints should either be fixed or deleted. A maintained suite is small and trustworthy; an unmaintained one is large and ignored.

Review tests like you review code. When code changes, the test changes too — and both go through the same PR review. A test that's never reviewed becomes a permanent legacy artefact.

The senior signal: treating the test suite as a product itself, with its own owners, debt, and pruning cadence — not as a write-once artefact.