skills.rest
joshhornby
joshhornbyCOMMUNITY
Explore all skills by this author →
Website𝕏@joshua_hornbyGitHub

front-end-testing

Write behavior-driven UI tests using Vitest Browser Mode, Playwright E2E, and Testing Library.

Updated May 18, 2024
Search Tags:#vitest#accessibility#playwright#e2e testing#testing library#front-end testing#msw
One-click install
npx skills add https://github.com/joshhornby/dotfiles --skill front-end-testing-joshhornby
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: front-end-testing
Source: https://github.com/joshhornby/dotfiles/tree/main/.claude/skills/front-end-testing
Command: npx skills add https://github.com/joshhornby/dotfiles --skill front-end-testing-joshhornby

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Front-end tests often break on refactors or pass while real bugs slip through because they test implementation details instead of user-visible behavior. This Skill provides patterns for writing UI and end-to-end tests that mirror how users actually interact with the application, so tests survive refactors and catch real defects. ## Core Features & Use Cases - Harness Selection Guidance: Choose between Vitest Browser Mode, jsdom, and Playwright E2E based on whether the claim depends on real rendering, CSS, focus, or browser APIs. - Accessibility-First Queries: Prioritize getByRole and other accessible locators over testIds and querySelector, with auto-retrying assertions via expect.element(). - E2E Evidence Boundaries: Enforce the rule that browser or user-journey claims must be proved by real browser initiators, never by direct HTTP calls standing in for the user. - Use Case: When writing a Playwright test for a sign-up flow, the Skill directs you to drive the form through accessible locator actions and assert the rendered outcome, rather than calling the API endpoint directly and falsely claiming journey coverage. ## Quick Start Ask the AI to write a Vitest Browser Mode test for a login form that types into labelled fields, clicks the submit button, and asserts the success message appears.

Frequently Asked Questions about front-end-testing

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

FAQPage Schema
How do I test front-end components without testing implementation details?▼

Drive the UI the way a user would: type into labelled fields, click buttons by role and accessible name, and assert what the user sees. Avoid asserting internal state, private methods, or CSS classes, since those break on refactors without indicating real bugs.

Vitest Browser Mode vs jsdom: which should I use for UI tests?▼

Use Vitest Browser Mode when the claim depends on real rendering, CSS, focus management, accessibility, or browser APIs. Keep a jsdom or happy-dom harness when it sufficiently proves pure logic or component contracts without browser-specific behavior.

What is the correct query priority in Testing Library?▼

Prefer getByRole with an accessible name first, then getByLabelText, getByPlaceholder, getByText, and others, with getByTestId only as a last resort. Accessible queries mirror how screen readers find elements and force semantic HTML.

Can I use page.request to test user journeys in Playwright?▼

No. A user-journey claim must be proved by a browser initiator such as an accessible locator action or navigation. Direct HTTP calls bypass the UI handler, cookie policy, CSRF checks, and rendering, so they only prove an HTTP contract, not a journey.

Should I use MSW setupServer or setupWorker in Vitest Browser Mode?▼

Use setupWorker from msw/browser in Browser Mode, since tests run in a real browser and setupServer only patches Node request modules. Use setupServer from msw/node for Node, jsdom, or happy-dom environments.

Why are my Playwright tests flaky when run in parallel?▼

Flakiness usually comes from non-idempotent tests that share state such as database rows, localStorage, or cookies. Each test must create its own state with unique identifiers, clean up after itself, and never depend on another test's side effects.

Related Skills

Explore More Software Engineering Skills→
eric-sabeeric-sabe
1

frontend-testing

Standardize Vitest, React Testing Library, and Playwright test practices for React and Next.js.

Community
Advanced
duynhneduynhne

playwright-expert

Automate end-to-end browser testing with Playwright across Chromium, Firefox, and WebKit.

Community
Intermediate
jaydubya818jaydubya818

testing-patterns

Guide Jest testing patterns with factory functions, mocking, and TDD workflows.

Community
Intermediate
thomasttvothomasttvo

figma-dev

Convert Figma designs into React components and verify visual parity via MCP.

Community
Advanced