mcpField
R
react-testing

react-testing

github.com/josiahsiegelTesting & quality5973 installsUpdated 19w ago
Repository

About react-testing

react-testing is a skill for developers writing React tests centered on user behavior. It covers test setup, interactions, async UI, integration, and accessibility, with guidance for common testing pitfalls.

Key features

  1. 01Vitest and Jest setup
  2. 02Accessibility-oriented queries
  3. 03userEvent interaction tests
  4. 04Async UI and hook testing
  5. 05Provider-aware render utilities
  6. 06Media and browser API mocks

Use cases

  1. 01Set up a React test runner
  2. 02Verify forms and interaction flows
  3. 03Test async UI and context-wrapped components
  4. 04Check accessibility states and mock media behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill react-testing

After installing, type/react-testingin Claude Code to confirm it loaded.

Bundled filesreferences/react-testing-complete-guide.mdreferences/testing-recipes.md

Details

From the project README

React Testing Skill

Use this skill for React tests that focus on user behavior: Vitest/Jest setup, Testing Library queries, user-event flows, async UI, hooks, providers, mocks, integration tests, accessibility checks, and media component tests.

When to Use This Skill

Use when the user asks for tasks covered by the frontmatter triggers, especially implementation guidance, debugging, architecture choices, production hardening, or performance-sensitive decisions in this domain. Start from this orchestrator, then load the focused reference file that matches the requested detail level.

Core Workflow

  1. Set up the runner and jsdom environment first, then centralize @testing-library/jest-dom, cleanup, and browser API mocks in test setup.
  2. Write tests from the user perspective using role, label, text, placeholder, and display-value queries before falling back to test IDs.
  3. Use userEvent.setup() for interactions and waitFor or findBy queries for async state changes.
  4. Mock at module or network boundaries, not internal component state, and reset mocks between tests.
  5. Create provider-aware render utilities for context, routers, query clients, themes, and other app-wide wrappers.
  6. For media components, mock jsdom gaps such as HTMLMediaElement.play, pause, load, metadata properties, and IntersectionObserver.

Key Gotchas

  • Avoid asserting implementation details such as component state; assert visible behavior and accessibility state.
  • fireEvent is lower-level than userEvent; prefer userEvent unless directly firing browser/media events is necessary.
  • Async assertions should wait for UI changes, not arbitrary timers.
  • jsdom does not implement real media playback, layout, or browser codecs; mock those APIs deliberately.
  • Provider state can leak between tests unless render utilities create fresh clients and cleanup runs after each test.

Reference Map

Response Guidance

  • Preserve the user's existing framework, library, and tooling choices unless there is a clear compatibility or performance reason to suggest an alternative.
  • Give copy-pasteable code only for the exact task at hand; otherwise point to the relevant reference section.
  • Call out tradeoffs, failure modes, and verification steps for production workflows.
  • Prefer accessible, maintainable, measurable solutions over clever micro-optimizations.

Comments

Markdown supported