Adopt Testing Library queries for interactive/accessible-element assertions
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 6
- Forks
- 1
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 10
Description
TL;DR: The recurring test-coverage gap tracked in #133 (new interactive behavior landing untested) keeps taking the same shape: specs assert on wrapper.props(...) passed into a stubbed child, not on the actual rendered DOM/accessible state. @vue/test-utils's API makes that the easy thing to reach for. Testing Library's query-by-role/label/accessible-name style makes the wrong thing hard to write instead of relying on someone remembering to write the right one.
Detail
Why this is a different fix than #133
#133 states the rule ("assert on the rendered effect, not the prop passed into a mock"), but a written rule still depends on someone applying it — and the API itself works against that: item.props('active') is one call away, while asserting on real aria-current/aria-pressed state on the actual rendered element takes more effort with @vue/test-utils alone. Testing Library's design principle is the opposite: getByRole('link', { name: 'Documents', current: 'page' }) structurally cannot pass unless the real DOM has the real attribute — there's no props-only shortcut available.
Concretely, this would have caught the #130 sidebar-dedupe bug (two nav entries both getting aria-current="page"): a query like getByRole('link', { current: 'page' }) returning more than one element is a direct, obvious assertion failure, whereas checking items.map(i => i.props('active')) never touches the actual collision.
Proposed scope
- Add
@testing-library/vue(verified:8.1.0,vue: >= 3peer dep, published 2026-08-07) and@testing-library/jest-dom(verified:7.0.1, published 2026-08-09) alongside the existing@vue/test-utilssuite — not a replacement.@vue/test-utils'sshallowMount/prop-based assertions remain fine for pure logic/wiring checks where DOM fidelity isn't the point. - Use Testing Library queries specifically for assertions on interactive elements and accessible/ARIA state (links, buttons,
aria-current,aria-pressed, accessible names) — the exact category of thing #133's rule targets. - One real worked example first, same approach as the composables adoption in #134: retrofit the #130 nav-dedupe fix (once merged) with a Testing-Library-style regression test, proving the pattern catches what the props-only assertion missed, before it spreads elsewhere.
Related
- #133 — states the rule this tooling enforces structurally rather than by convention.
- #134 — same "introduce one pattern via one real example, then let it spread opportunistically" shape.
Found during review of #125/#127/#130, all three of which hit this same gap independently.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing @vue/test-utils suite and the proposed @testing-library/vue and @testing-library/jest-dom additions. Use the #130 nav-dedupe regression as the first example once that fix is merged, focusing on interactive elements and accessible state. Done means one real test demonstrates that Testing Library queries catch duplicate aria-current state while preserving prop-based tests for wiring checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100