frontend-testing

Write behavior-driven DOM tests with Testing Library queries, userEvent, and async patterns.

3|Updated Nov 8, 2014
One-click install
npx skills add https://github.com/mintuz/.dotfiles --skill frontend-testing-mintuz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: frontend-testing
Source: https://github.com/mintuz/.dotfiles/tree/main/agents/.agents/skills/frontend-testing
Command: npx skills add https://github.com/mintuz/.dotfiles --skill frontend-testing-mintuz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Front-end tests often break on refactors or pass while bugs exist because they target implementation details instead of user-visible behavior. This Skill guides you to write DOM tests that mirror how users interact with your UI, reducing false negatives and false positives. ## Core Features & Use Cases - Accessibility-first query selection: Prioritize getByRole and getByLabelText over test IDs and CSS selectors, with clear guidance on query variants (getBy, queryBy, findBy). - Realistic user interactions: Use userEvent.setup() patterns for clicks, typing, and keyboard input instead of low-level fireEvent calls. - Async and network testing: Handle loading states, debounced inputs, and API responses with findBy, waitFor, and MSW network-level mocking. - Use Case: When writing a Vitest or Jest test for a login form, this Skill directs you to mount the component, type into labeled fields with userEvent, click the submit button by role, and assert the callback fired exactly once. ## Quick Start Write a DOM test for my login form that types an email, clicks submit, and verifies the submit handler was called once.

Frequently Asked Questions about frontend-testing

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

FAQPage Schema
How do I test front-end UI with Testing Library?▼

Mount your markup, then query elements the way users find them: getByRole with an accessible name first, then getByLabelText or getByText. Drive interactions with userEvent.setup() and assert user-visible outcomes with jest-dom matchers like toBeInTheDocument.

userEvent vs fireEvent: which should I use?▼

Use userEvent for realistic interactions because it dispatches the full pointer, focus, and mouse event sequence a browser fires. Reserve fireEvent only for events userEvent does not support, since single synthetic events can hide bugs.

When should I use getBy, queryBy, or findBy queries?▼

Use getBy when the element must already exist, queryBy when asserting an element is absent since it returns null, and findBy when the element appears after async work since it waits and retries until a timeout.

Can I test end-to-end user journeys with jsdom?▼

No, jsdom cannot navigate between documents, so cross-page journeys, redirects, downloads, and real cookie behavior need Playwright or Cypress. jsdom also cannot test visual appearance since it does not lay out or paint.

Should I mock fetch or use MSW for API testing?▼

Use MSW when the test crosses the network boundary, since it intercepts requests at the network level and works in tests, Storybook, and dev servers. When a component receives its request function by injection, pass a mock function instead.

Why does my absence assertion pass even when the component is broken?▼

An absence assertion made right after an interaction may run before the component reacts, passing regardless of correctness. Anchor it to a state that only exists after async work finished, such as awaiting findByRole('status') before asserting queryByRole('alert') is null.