accelint-react-testing_skill

This skill helps you write, review, and refactor React tests with Testing Library, emphasizing accessible queries and user-centric interactions.
  • TypeScript

6

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill gohypergiant/agent-skills --skill accelint-react-testing

  • AGENTS.md3.2 KB
  • README.md3.4 KB
  • SKILL.md14.8 KB

Overview

This skill provides concise, opinionated guidance for writing, reviewing, and refactoring React component tests using Testing Library. It enforces accessibility-first query selection, realistic user interactions, and reliable async handling to produce maintainable, user-centric tests. Use it to detect anti-patterns and apply concrete fixes or generate standardized review reports.

How this skill works

The skill inspects test files and patterns such as render(), screen, fireEvent, userEvent, waitFor, and *.test.tsx files. It flags unsafe patterns (testId-first queries, fireEvent over userEvent, container usage, implementation-focused asserts) and recommends replacements following query priority and async best practices. It can also run audit scripts to produce a prioritized report with impact and remediation guidance.

When to use it

  • Writing new component tests to guarantee accessibility and user-centric behavior
  • Reviewing or refactoring test suites that use render(), container, or destructured queries
  • Fixing flaky async tests that misuse waitFor or getBy vs findBy
  • Converting fireEvent usage to realistic userEvent interactions
  • Creating or documenting custom render helpers for provider-wrapped components

Best practices

  • Prefer accessible queries: getByRole > getByLabelText > getByText > getByTestId (last resort)
  • Always use screen.* queries instead of destructured returns from render() to avoid stale queries
  • Use userEvent for interactions to simulate real event sequences; avoid fireEvent when userEvent is available
  • Use findBy* for elements that appear asynchronously; use waitFor only when findBy/findByElementToBeRemoved don't apply
  • Never assert implementation details (state variables, internals); test outcomes users see and do
  • Document custom render utilities and required provider shapes; centralize provider setup in test utils

Example use cases

  • Audit a repository for testId overuse and generate fixes to replace with getByRole/getByLabelText
  • Refactor flaky tests that relied on container or destructured queries to use screen and findBy
  • Replace fireEvent sequences with userEvent to catch interaction regressions
  • Create a custom renderWithProviders utility and document required contexts and types
  • Produce a prioritized review report showing accessibility confidence, test reliability, and remediation steps

FAQ

Only when no accessible attribute or role is possible and you have verified adding semantic markup is impossible; treat it as a last resort and document why accessibility queries cannot be used.

Why prefer screen over destructured queries from render()?

screen queries the current document and never becomes stale after re-renders, avoiding elusive 'element not found' errors caused by snapshot queries captured at initial render.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational