jest-dom-aria-assertion-pattern

Moves ARIA attribute assertions from DOM matchers to pure helper functions in React component tests.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill jest-dom-aria-assertion-pattern-vilnacrm-org
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: jest-dom-aria-assertion-pattern
Source: https://github.com/VilnaCRM-Org/claude-plugins/tree/main/plugins/react-frontend-sdlc/skills/jest-dom-aria-assertion-pattern
Command: npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill jest-dom-aria-assertion-pattern-vilnacrm-org

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? ESLint rules jest-dom/prefer-required and jest-dom/prefer-to-have-attribute push ARIA attribute assertions back and forth when tests assert on Testing Library query results, and toBeRequired() cannot distinguish native required from aria-required. This Skill resolves the lint loop by moving ARIA emission logic into a pure helper module and asserting on the returned object instead of the DOM node. ## Core Features & Use Cases - Pure helper extraction: Moves aria-required and aria-describedby computation into a standalone module beside the component, with the component spreading the result. - Lint-loop resolution: Assertions on plain objects fall outside jest-dom rule scope, so neither prefer-required nor prefer-to-have-attribute rewrites them. - Mutation testing support: Pins ARIA-computing branches that render identically, killing mutation survivors reported by the mutation test target. - Use Case: A React input component joins helper-text and caller-supplied aria-describedby ids; instead of asserting toHaveAttribute on the rendered element, the test asserts describedBy('helper-1', 'caller-2') returns { 'aria-describedby': 'helper-1 caller-2' }. ## Quick Start Refactor my component test that asserts aria-required with toHaveAttribute so the ARIA logic lives in a helper module and the test asserts on its returned object.

Frequently Asked Questions about jest-dom-aria-assertion-pattern

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix jest-dom/prefer-required and prefer-to-have-attribute ESLint errors?▼

Move the ARIA emission logic into a pure helper module and assert on the object it returns instead of a Testing Library query node. The jest-dom rules only fire when the expect argument is a DOM node, so plain-object assertions fall outside their scope.

How to test aria-required in React Testing Library?▼

Extract the ARIA computation into a helper like inputAria(required) returning { 'aria-required': 'true' } or an empty object, then assert with toEqual on the returned value. The component spreads the result, keeping the DOM contract unchanged.

Why does toBeRequired pass for both required and aria-required?▼

toBeRequired() matches both the native required attribute and aria-required="true", so the test cannot prove which one the component emits. Asserting on a helper's returned object pins the exact attribute contract, including the absent-attribute case.

Does this pattern work with Next.js and component libraries?▼

Yes, the pattern applies to React SPA, Next.js, and Storybook-first component-library shapes. Next.js allows plain exported helper functions, while the React SPA shape requires instance methods on a singleton class with types in a types/ file.

When should I not use the ARIA helper assertion pattern?▼

Do not use it for assertions about visible text, roles, or focus, which should stay as idiomatic DOM matchers. Also keep a DOM test asserting the element renders with the right role so a helper that is computed but never spread still fails.