## TL;DR

Trace from the component to its tests: search for its selectors, its page objects, and its route mocks. Run the affected subset, not the whole suite, for fast feedback.

## Error

```text
(Not an error; an impact analysis. The need: "what breaks if I change this component?")
```

## Steps

1. Search tests for the component's test IDs and selectors. Expected: the direct test list.
2. Search for its page objects and helpers. Expected: indirect coverage found.
3. Search for its API routes in mocks. Expected: integration tests found.
4. Run the affected subset. Expected: fast, relevant feedback.
5. After the change, run the full suite once. Expected: no surprises outside the subset.

## When to use

- Changing shared components.
- Planning test updates for a refactor.

## When not to use

- Trivial changes (just run the suite).
- You have no selector conventions (fix that first).

## Tool compatibility

- Any framework; grep/ripgrep for tracing.

## Variant phrasings

### Test impact analysis

The general practice; selector tracing is the method.

### Which tests cover this component

The question; the searches answer it.

## Why it happens

Tests reference components indirectly through selectors and helpers. Explicit tracing beats guessing.

## Edge cases

- Visual tests cover components implicitly; include them.
- Shared helpers mean one component change affects many files; the helper is the choke point.
- Keep a component-to-test map for the most-shared components.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LM-uzsjwMOaUJSzT5B195w