frontend-testing

Define frontend tests for user-visible behavior across roles and UI states.

4|Updated May 16, 2026
One-click install
npx skills add https://github.com/machenjie/rd-skills --skill frontend-testing-machenjie
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: frontend-testing
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/frontend-testing
Command: npx skills add https://github.com/machenjie/rd-skills --skill frontend-testing-machenjie

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Frontend tests often break during harmless refactors or fail to catch real user-visible regressions, especially across permission states and accessibility-critical interactions.

Core Features & Use Cases

  • Behavior-first frontend verification: Designs tests that assert what users can see and do (roles, labels, validation messages, recovery actions) rather than brittle internal implementation details.
  • Comprehensive state coverage: Ensures loading, empty, success, error (with recovery), disabled, and stale behaviors are explicitly validated with behavioral assertions.
  • Permission-differentiated fixtures: Requires distinct test cases for each role/permission variant so lower-access views and permission-denied scenarios are never assumed.
  • Contract-aligned API mocking: Promotes MSW-style mocks that match the DTO/OpenAPI contract to prevent false confidence from mis-shaped fixtures.

Quick Start

Ask the AI to generate Testing Library integration tests that validate role-specific UI, user-visible states (loading/empty/error+recovery), accessible queries, and MSW contract-aligned API mocks for your changed frontend component.

Frequently Asked Questions about frontend-testing

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

FAQPage Schema
How do I write frontend tests that don't break during refactors?

Frontend tests that verify user-visible behavior survive refactors by asserting roles, labels, and validation messages rather than brittle internal implementation details. This approach uses Testing Library query priority to focus on behavioral assertions over internal component state.

What's the best way to test permission-differentiated rendering in a UI?

Testing permission-differentiated rendering requires distinct test cases for each role variant using permission fixtures. This ensures lower-access views and permission-denied scenarios are explicitly validated rather than assumed, catching real user-visible regressions across access levels.

How does MSW mocking prevent false confidence in frontend tests?

MSW mocking prevents false confidence by enforcing contract-aligned API mocks that match the DTO or OpenAPI contract. This stops mis-shaped fixtures from passing tests, ensuring your frontend testing validates actual API-driven UI variations and dynamic states accurately.

Can I test error recovery and async loading states without timeouts?

Yes, you can validate error recovery and async loading states without timeouts by using deterministic async handling. This approach enforces behavioral assertions for recovery actions across loading, empty, success, error, disabled, and stale UI states explicitly.

When do I need behavior-driven frontend testing for my component changes?

You need behavior-driven frontend testing for component or route-level changes involving DOM output, permission-differentiated rendering, form UX, and API-driven UI variations. It verifies accessible queries and user-visible states to ensure frontend UX works for every role.