agentleFS
practicajspracticajs/the-frontend-testing-skill/CLAUDE.md

the-frontend-testing-skill

CLAUDE.md13 starsChanged 26 days agoMITView on GitHub

This is The Frontend Testing Skill - a Claude Code skill that orchestrates comprehensive frontend test writing and verification. It provides specialized agents, commands, and best practices documentation for testing workflows. Core Philosophy: The "Double Gate πŸŒ‰ Principle" - test planning is the first task in any workflow, test verification is the last. Testing is integrated throughout development, not separate. Explainer deck code slides: any "show the code" slide in docs/explainer-deck/ must use the EditorMock component (GitHub diff-header style —…

  • Installs packages

The file

We split this CLAUDE.md into the rules it gives an agent

9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • β‰ˆ0

    Common Β· estimate

    Many files like this have a rule of this kind.

  • β‰ˆ6

    Distinctive Β· estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before writing tests: Must have test-plan.md (from testskill.planner)

    line 113
  2. Very specific:

    Before writing tests: Must have page-analysis.md (from testskill.page-analyzer)

    line 114
  3. Distinctive:

    After writing tests: Must run testskill.verifier

    line 115
  4. Distinctive:

    No more than 10 statements per test

    line 128
  5. Distinctive:

    Never mock internal parts - only external systems

    line 131
  6. Distinctive:

    Smoking Gun Principle: Every assertion value must appear first in arrange phase

    line 132
  7. Very specific:

    When installing the skill in a project, config.toml controls:

    line 141
  8. Distinctive:

    Paths: Test context artifacts location

    line 146
  9. Distinctive:

    Unit Testing: - Only for heavy logic with high combinatorial inputs

    line 153

β‰ˆ β€œCommon” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. β€œVery specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
CLAUDE.md

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Project Overview

This is The Frontend Testing Skill - a Claude Code skill that orchestrates comprehensive frontend test writing and verification. It provides specialized agents, commands, and best practices documentation for testing workflows.

Core Philosophy: The "Double Gate πŸŒ‰ Principle" - test planning is the first task in any workflow, test verification is the last. Testing is integrated throughout development, not separate.

Repository Structure

the-frontend-testing-skill/
β”œβ”€β”€ plugin/frontend-testing/     # β˜… SOURCE OF TRUTH β€” the distributable skill
β”‚   β”œβ”€β”€ agents/                  # specialized agents
β”‚   β”œβ”€β”€ commands/                # slash command definitions
β”‚   └── skills/frontend-testing/ # core docs & config (config.toml, test-workflow.md, patterns-and-practices/)
β”œβ”€β”€ example-app-playwright/      # Demo app β€” embeds a copy of the skill under .claude/
β”œβ”€β”€ example-app-vitest-browser/  # Demo app β€” embeds a copy of the skill under .claude/
β”œβ”€β”€ .claude/skills/skill-maintenance/  # Repo-maintainer skill (review, sync, sanity-test)
β”œβ”€β”€ the-testing-skill/           # DEPRECATED β€” ignore
└── docs/demo/                   # Presentation materials

Explainer deck code slides: any "show the code" slide in docs/explainer-deck/ must use the EditorMock component (GitHub diff-header style β€” no terminal/traffic-light chrome). See Code frame standard in docs/explainer-deck/decks/frontend-testing-explainer/CLAUDE.md.

Source of Truth & Maintenance

  • Canonical source: plugin/frontend-testing/ is what ships to users. Edit the skill here.
  • Example apps are targets: the two demo apps embed a copy under their .claude/. Propagate changes with the maintenance skill, don't hand-edit copies.
  • the-testing-skill/ is deprecated β€” ignore it.

Small-change discipline (when editing the skill directly): keep changes small (ideally 1–3 lines, single file), routed to exactly one correct target file (patterns β†’ patterns-and-practices/, workflow β†’ test-workflow.md, config keys β†’ config.toml, a command's behavior β†’ its commands/testskill.*.md). Don't mix topics. Get user approval, then bump the version (metadata.version + VERSION).

Maintenance skill β€” just ask in chat (.claude/skills/skill-maintenance/):

  • review β€” audit the skill against the agentskills.io spec, broken links, content placement, quick wins
  • install local β€” wire one named example app to the local marketplace
  • sync up β€” pull one named example app back to root (templates config)
  • sanity test β€” build a feature with the skill end-to-end, verify tests, then clean up (single app, or example-monorepo per package)

Development Commands

Example App: Playwright (example-app-playwright/)

cd example-app-playwright && pnpm install

pnpm dev                  # Start dev server (port 5173)
pnpm test:page            # Run Playwright page tests
pnpm test:page:ui         # Run Playwright tests with UI
pnpm test:unit            # Run Vitest unit tests
pnpm test:storybook       # Run Storybook tests
pnpm lint --fix           # Fix lint errors

Example App: Vitest Browser (example-app-vitest-browser/)

cd example-app-vitest-browser && pnpm install

pnpm dev                  # Start dev server (port 5173)
pnpm test:browser         # Run Vitest browser mode tests
pnpm test:browser:headed  # Run browser tests with visible browser
pnpm test:unit            # Run Vitest unit tests
pnpm lint --fix           # Fix lint errors

Running Single Tests

# Playwright (from example-app-playwright/)
pnpm test:page -g "test title pattern"
pnpm test:page path/to/test.spec.ts

# Vitest (from either example app)
pnpm test:unit -t "test title pattern"
pnpm test:browser path/to/test.browser.tsx

Skill Commands (Slash Commands)

CommandPurpose
/testskill.write-test <page-name>Full workflow: plan β†’ analyze β†’ write β†’ verify
/testskill.plan <page-name>Create test plan only
/testskill.verify <test-plan.md-path>Verify tests after writing
/testskill.review <test-file-path>Review test file against best practices
/testskill.initInitialize skill in a project

Agents

AgentRole
testskill.plannerCreates test plans with coverage targets
testskill.page-analyzerInspects live app for network calls, state, UI structure
testskill.verifierRuns tests, checks quality, generates reports
testskill.healerDebugs and fixes failing tests
testskill.locator-fixerAdds ARIA attributes for stable selectors

Mandatory Workflow

VIOLATION WARNINGS will be printed if these are not followed:

  1. Before writing tests: Must have test-plan.md (from testskill.planner)
  2. Before writing tests: Must have page-analysis.md (from testskill.page-analyzer)
  3. After writing tests: Must run testskill.verifier
  4. Every task list: First task = test planning, Last task = test verification

Critical Files to Read

  1. the-testing-skill/skills/testing/test-workflow.md - The mandatory workflow sequence
  2. the-testing-skill/skills/testing/patterns-and-practices/the-test-anatomy.md - 6 critical rules
  3. the-testing-skill/skills/testing/config.toml - Configuration template

Test Writing Rules (Summary)

The 6 most critical rules from the-test-anatomy.md:

  1. No more than 10 statements per test
  2. Include only details that affect test results - no unnecessary details
  3. Totally flat: no if/else, loops, try-catch, console.log
  4. Never mock internal parts - only external systems
  5. Smoking Gun Principle: Every assertion value must appear first in arrange phase
  6. Tests are self-contained - never rely on other tests' state

Test title pattern: When {scenario}, then {expectation}

Test structure: AAA (Arrange-Act-Assert) with clear phase separation

Configuration (config.toml)

When installing the skill in a project, config.toml controls:

  • Workflow enforcement: stop_when_no_plan, stop_when_no_page_analysis, must_have_human_review_of_plan
  • Frameworks: vitest, vitest-browser-mode, playwright, msw
  • Commands: App start/stop, test run, git staging
  • Paths: Test context artifacts location
  • Canonical example: Path to a reference test file in the target project

Test Types (Priority Order)

  1. Page Testing (Primary) - Single page scope, one meaningful user action per test
  2. Component Testing - Reusable components and design system libraries
  3. Unit Testing - Only for heavy logic with high combinatorial inputs

Test only external outcomes: UI changes users notice, API mutations, storage changes. Never test implementation details.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.