Your team's React Testing Library suite is green on every pull request, yet UI regressions keep reaching production. A review shows tests built almost entirely on test ids, mocked-out child components, and assertions against store state. As the lead, how do you decide what to change and in what order?

## First, name what is actually broken The suite is green and regressions still ship, so the suite is insensitive, not incomplete. That distinction drives everything. Adding more tests of the same kind makes the numbers better and the product no safer. The three patterns found in review each remove sensitivity in a specific way: - **test ids everywhere** — the test finds the node no matter what the node says, so label, copy and reachability regressions pass; - **mocked children** — the composed UI never renders, so every parent-to-child integration bug passes; - **state assertions** — the render half of the component's job is never checked, so stale views and formatting bugs pass. Stack them and you have a suite that verifies the code executes, which is roughly what a coverage tool already told you. ## Measure sensitivity before you spend anyone's quarter The most persuasive move is cheap: take five to ten recent production regressions, reintroduce each one on a branch, and run the suite. Then do the same with synthetic breakages — remove a button's accessible name, render the wrong field, make a child render nothing, format a number wrong. Count how many the suite catches. The output is a single number — "our tests catch 3 of 10 real regressions" — that survives contact with a planning meeting in a way "our tests are low quality" does not. It also localises the damage: if the misses cluster in pages whose children are stubbed, that is where the first fixes go. This is a poor engineer's mutation testing, and if the codebase can afford a real mutation-testing run, use that instead; the reasoning is identical. ## Sequence by risk, and prefer opportunistic conversion A big-bang migration of an old suite is the classic way to burn a quarter and get halfway. Better ordering: 1. **Flows where an escape actually hurt** — checkout, payment, auth, anything that generated an incident. Rewrite those tests properly now, on purpose, with time allocated. 2. **Files under active change.** Attach conversion to work already touching the file, so the cost lands where somebody is already paying attention. 3. **Everything else: leave it.** An insensitive test that costs nothing to keep is not worth a rewrite budget on its own. It becomes worth rewriting the day it obstructs a change. An important corollary: delete rather than convert where the test asserts nothing meaningful. A test whose only assertion is that a stub received a prop can go, and the honest coverage number that results is more useful than the fiction it replaces. ## Remove the reason the pattern happened Every one of these mistakes is usually a workaround for friction, and if the friction stays, the pattern comes back into every new test. - People stub children because setup is painful → give them a custom render that wires the real providers, plus realistic fixture builders, so rendering the true tree is the path of least resistance. - People use test ids because role queries are awkward → some of that is missing labels in the product, which is a real bug worth fixing; the rest is unfamiliarity, which one worked example fixes. - People assert on store state because nothing visible is easy to assert → that often means the component's responsibilities are split badly, and it is worth looking at. Then make the new default stick: a short written convention, lint rules where the ecosystem provides them, and — most effective in practice — reviewing new tests with the same seriousness as production code. One senior engineer consistently asking "what would this test catch?" changes a team's habits faster than any document. ## What you deliberately do not do - Do not chase a coverage target; it is the metric that produced this suite. - Do not respond by pushing everything to end-to-end tests. They are slower, flakier and more expensive per assertion; the right fix is component tests that actually assert. - Do not rewrite the suite silently as a side project. The number from the sensitivity exercise is what buys the time. ## Close the loop Re-run the breakage exercise a quarter later on the converted areas and report the delta, alongside escaped-defect counts for those flows. That is what makes it a completed piece of engineering leadership rather than an opinion about test style — and it is what an interviewer at this level is listening for: a diagnosis, a sequencing rule tied to risk, a change to the defaults so the debt stops growing, and evidence at the end.