how to audit data-testid coverage across the app

TL;DR

Audit data-testid coverage with two scans: a static scan of the source that flags interactive elements missing the attribute, and a runtime scan of the rendered DOM that catches what third-party components render. Post the delta on every PR so authors see new gaps before merge. Coverage only improves if the report is visible where the code is written.

The query

how to audit data-testid coverage across the app

Use this when

• E2E selectors break on every UI restyle because they target classes or text
• You want a "how testable is our UI" metric that trends over time
• A team rule says new components need test ids and nobody is checking
• An agent is healing selectors and keeps hitting untestable elements

Not for

• Accessible-name coverage (screen-reader labels are a separate audit)
• Unit test coverage numbers
• Picking a selector strategy for a single test

Steps

1. Define what counts as interactive

Buttons, links, inputs, selects, textareas, and any element with an onClick or keyboard handler are in scope. Plain divs and spans used for layout are not.

Expected output: a written list of element types and attributes the audit will check, agreed on before any code is written.

2. Run a static scan over the source

Parse the JSX/TSX files with an AST walker and flag interactive elements that have no data-testid attribute. An AST script beats regex here because regex misses spread props and conditional attributes.

Expected output: a per-file list of offending elements with line numbers.

3. Run a runtime scan of the rendered pages

Load the key pages in a test browser, walk the DOM, and flag interactive elements with no test id. This catches what the static scan cannot: third-party widgets, portal-rendered modals, and elements injected by libraries.

Expected output: a second gap list that includes third-party-rendered elements the source scan missed.

4. Post the delta on every pull request

Report how many gaps the PR adds versus fixes as a PR comment or check. Authors see the number before merge; reviewers get a concrete thing to ask about.

Expected output: a PR comment showing added-versus-fixed gaps for that change.

5. Track the trend weekly

Graph total open gaps over time. A flat or falling line means the rule is working; a rising line means the PR gate is being ignored.

Expected output: a weekly chart of open gaps, reviewed wherever the team already talks about quality.

6. Cross-check test usage

Scan the test suite for getByTestId calls and list test ids that exist in tests but not in the source. A test id referenced by a test but missing from the app is a broken test waiting to happen.

Expected output: a list of orphaned test-id references to fix or delete.

Variant phrasings

how to find elements missing data-testid

Same as steps 2 and 3: static scan first, runtime scan second. The static scan is cheap and catches most of it.

data-testid coverage report for e2e tests

Same as steps 4 and 5. The report is only useful if it shows up on PRs and trends over time.

enforce test ids in CI

Steps 2 and 4 combined: run the static scan as a CI check and fail (or warn) when a PR adds new gaps.

Why it happens

Tests written against CSS classes or visible text break whenever the UI is restyled, which is constantly. data-testid is the stable contract between the app and its tests, but nobody adds the attribute voluntarily because it feels like test code polluting product code. Without an audit that reports the gap count where developers actually see it, coverage stays wherever it happened to land.

Edge cases

• Third-party components that render their own DOM cannot take your test ids: cover those with role-based or accessible-name selectors instead, and exclude them from the audit.
• Spread props can hide a data-testid from a naive scan: check the resolved props, not just the literal attribute list.
• Portals and modals render outside the page root: the runtime scan must walk the full document, not just the app container.
• Playwright lets you rename the attribute via testIdAttribute if your codebase uses a different convention: configure the audit to match the convention, not the other way around.
• A 100 percent coverage target is a trap: interactive elements inside generated or vendored code will never comply. Aim for coverage of first-party interactive elements, and exempt the rest explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O8IN2AOCvwlH1Pq0GRcM8g