21 skills · category

Testing skills for Claude Code

Skills for test suites worth trusting: unit test design, Playwright end-to-end tests, Vitest, pytest, Testing Library, mocking boundaries, contract tests, k6 load tests, property-based and mutation testing, visual regression, test data factories, and flaky test triage.

Download all 21 (.zip) Browse the list

Every testing skill

Each card opens the full playbook, example prompts and install commands.

No. 125

API Testing

Prove every endpoint's contract, including who can't call it

Claude picks one API test format for the repo, builds an endpoint-by-case matrix that includes validation errors, expired tokens, wrong roles and cross-tenant access, and writes self-contained tests that create their own data. Responses are checked against the OpenAPI schema plus the fields each case is about, and CI runs the suite against a fresh container with JUnit output and service logs.

api-testing 254 lines

No. 126

Benchmark Testing

Faster means significant, not one lucky run

Claude stops quoting single-run timings. It uses the right harness per language, guards against dead-code elimination, quiets the machine, measures noise with an A/A run, and compares 10 or more samples per side with a significance test and confidence interval. CI gates get thresholds derived from measured noise, or instruction counts when shared runners are too jittery.

benchmark-testing 259 lines · 2 files

No. 127

Contract Testing

Catch breaking API changes before either side deploys

Claude picks between consumer-driven Pact contracts and provider-owned OpenAPI checks based on who the consumers are, then wires the full loop: consumer tests with type matchers, provider verification with named states, a broker, can-i-deploy before every deploy and record-deployment after. Breaking API changes fail a pipeline instead of a production release.

contract-testing 182 lines · 2 files

No. 128

Coverage Analysis

Find untested risk instead of chasing a percentage

Claude fixes how coverage is measured first (branch mode, all source files, merged shards), then reads the report for risk by combining missed lines with churn and business criticality. It gates pull requests on coverage of changed lines rather than the global number, and flags tests that execute code without asserting anything. A bundled script computes diff coverage from LCOV or Cobertura.

coverage-analysis 189 lines · 2 files

No. 129

Cypress E2E

Cypress tests that wait on aliases, never on timers

Claude writes Cypress specs that respect the command queue: stable data-cy or role selectors, retrying should assertions, intercept aliases instead of fixed waits, and cy.session logins with validation so each spec logs in once through the API. It seeds data with cy.task, adds component tests with cy.mount, and parallelizes CI through Cypress Cloud or free spec splitting.

cypress-e2e 260 lines

No. 130

Flaky Test Triage

Find flakes from CI data and fix the cause

Claude treats flakiness as a measurable defect. It aggregates JUnit reports from many CI runs to find tests that flip, ranks them by pipeline cost, quarantines the worst into a non-blocking job with an owner, reproduces them under repeat, shuffle and CPU stress, and only calls a fix done when the failure rate drops to zero over an equal number of runs.

flaky-test-triage 149 lines · 2 files

No. 131

Fuzz Testing

Throw hostile bytes at parsers before attackers do

Claude picks the input boundaries worth fuzzing, writes fast deterministic harnesses with real invariants such as round-trip equality, and seeds them with real inputs and format dictionaries. Crashes get reproduced, minimized, classified by sanitizer report and deduplicated by stack, then committed as regression inputs, and CI runs short fuzz jobs with a cached corpus.

fuzz-testing 259 lines · 2 files

No. 132

Jest Testing

Jest suites with hoisting-safe mocks and honest snapshots

Claude sets a single Jest config with per-project environments, a fast TypeScript transform and restoreMocks so state never leaks between tests. It writes module mocks that respect hoisting rules, uses async timer advancers when promises are involved, keeps snapshots small and reviewed, and walks a suite through the Jest 30 breaking changes such as removed matcher aliases and the renamed path flag.

jest-testing 242 lines

No. 133

Load Testing with k6

A verdict and a bottleneck, not just a pile of numbers

Claude starts every load test from a written question and SLO thresholds, then writes k6 scenarios with open-model arrival rates, tagged endpoints, and realistic data. After the run it reads tail percentiles rather than averages, finds the knee where latency climbs, checks for dropped iterations, and names the bottleneck in a short capacity report with a pass or fail verdict.

load-testing 190 lines · 2 files

No. 134

Mobile E2E Testing

Mobile UI tests that pass ten runs out of ten

Claude picks one end-to-end framework per app stack, adds stable test IDs and a launch-argument test mode that fixes backend, locale and animations, and writes journeys that reset state and wait on conditions rather than sleeping. It sets up emulator and simulator CI with artifacts on failure, uses device farms for real-device passes, and works through a flake checklist until runs are repeatable.

mobile-e2e-testing 275 lines

No. 135

Mocking Strategy

Mock the edges, run everything you own

Claude classifies every dependency before reaching for a mock: owned code runs for real, owned databases run in containers, third-party APIs sit behind an adapter and are stubbed at the HTTP layer. In-memory fakes share a contract suite with the real adapter, so a double that drifts from reality fails loudly instead of hiding a production bug.

mocking-strategy 161 lines

No. 136

Mutation Testing

Find out if your tests would notice a real bug

Claude runs mutation testing where it pays off, on critical modules or changed files, and triages every surviving mutant: missing boundary case, weak assertion, untested error path, equivalent mutant, or dead code. Survivors turn into small behavior-named tests, ignores carry a written reason, and CI gates only the modules that matter.

mutation-testing 167 lines

★ No. 137

Playwright E2E

End-to-end tests that never need a sleep

Claude writes Playwright tests the way the Playwright team recommends: role and label locators, auto-retrying assertions, API-seeded fixtures with teardown, and one login reused through storageState. When a test fails it reads the trace before touching code, and it ships CI config that shards runs, merges blob reports, and keeps traces for every failure.

playwright-e2e 220 lines · 2 files

No. 138

Property-Based Testing

Let the generator find the edge case you missed

Claude writes properties that state true facts about your domain, such as round-trips, invariants, and comparisons to a simple oracle, instead of restating the code. Generators build valid inputs directly rather than filtering, every shrunk counterexample becomes a pinned example test, and stateful components get model-based command sequences.

property-based-testing 213 lines · 2 files

No. 139

pytest Suites

Strict, fast pytest suites with clean fixtures

Claude sets pytest up strictly so typos in markers and config fail loudly, then designs fixtures with the narrowest safe scope, rollback-per-test database sessions, and factory fixtures instead of shared mutable data. Tests use parametrize with readable ids, tmp_path and monkeypatch, and the suite is proven green in random order and in parallel.

pytest-suites 213 lines

No. 140

Test Data Factories

Valid test data by default, only relevant fields shown

Claude replaces sprawling object literals and shared fixtures with one factory per entity that builds a valid object from zero arguments, uses sequences for unique fields, and exposes named traits. Tests show only the fields that drive the assertion, Faker is seeded for replay, and seed scripts or masked production subsets are built without copying real PII.

test-data-factories 200 lines

No. 141

Testcontainers

Real databases in tests, started once and reset fast

Claude replaces database mocks and H2 stand-ins with the production engine in a container, started once per run rather than per test. It runs the real migrations, picks rollback, truncation, template databases or snapshots for isolation, gives each parallel worker its own database, and sets up GitHub Actions or GitLab Docker-in-Docker so the suite passes cold, shuffled and in parallel.

testcontainers 202 lines · 2 files

No. 142

Testing Library

Component tests that query like a screen reader

Claude writes component tests that find elements by role and accessible name, drive them with awaited user-event calls, and assert on what a user would see. It builds one render helper with fresh providers per test, stubs the network rather than hooks, and fixes act() warnings by waiting for the visible result instead of wrapping calls in act.

testing-library 188 lines

No. 143

Unit Testing

Tests that survive refactors and catch real bugs

Claude stops writing tests that mirror the implementation. It lists observable behaviors first, picks boundary and error inputs on purpose, writes behavior-named arrange-act-assert tests with literal expected values, and breaks the code once to prove each new test can go red. Mocks stay at out-of-process edges, so the suite survives refactors.

unit-testing 188 lines · 2 files

No. 144

Visual Regression

Screenshot tests that fail on real change, not noise

Claude makes renders deterministic before touching thresholds: frozen clock, fixture data, loaded fonts, masked live widgets, and baselines generated inside the same Playwright container CI uses. It proves zero noise with repeated runs, then tunes per-snapshot limits so a one-pixel padding change fails while anti-aliasing jitter does not.

visual-regression 179 lines

No. 145

Vitest Testing

Vitest suites with no leaking mocks or hung timers

Claude configures Vitest so mocks restore themselves, each file runs in the right environment, and coverage counts every source file instead of only the ones a test touched. It knows the hoisting rules behind vi.mock, uses the async timer helpers when promises are involved, and maps Jest APIs one to one when migrating a suite.

vitest-testing 220 lines

Choosing Testing skills

Install the skills that match requests you make every week; each costs about 100 tokens of standing context until it loads. If you are not sure where to begin, start with Playwright E2E. For background, read The Best Claude Code Skills in 2026, by Use Case, How to Install Claude Code Skills (5 Ways) and Personal vs Project Skills.

By technology: Python skills TypeScript skills JavaScript skills Playwright skills Rust skills Java and Kotlin on the JVM skills GitHub Actions skills

Install several

Install several at once

The installer accepts any number of skill names. Add --project to install into the current repository.

curl -fsSL https://claudeskills.page/install.sh | sh -s -- api-testing benchmark-testing contract-testing coverage-analysis cypress-e2e flaky-test-triage fuzz-testing jest-testing load-testing mobile-e2e-testing mocking-strategy mutation-testing playwright-e2e property-based-testing pytest-suites test-data-factories testcontainers testing-library unit-testing visual-regression vitest-testing

Testing skills FAQ

How do I install every Testing skill at once?

Download the bundle at https://claudeskills.page/downloads/category/testing.zip and unzip it into ~/.claude/skills/ (or .claude/skills/ inside a repository). To pick a few, pass several names to the installer: curl -fsSL https://claudeskills.page/install.sh | sh -s -- api-testing benchmark-testing contract-testing.

Will installing 21 skills slow Claude Code down?

No. Claude Code keeps only each skill's short description in context — roughly 100 tokens per skill — and loads the full instructions only when a request matches. Install the whole category if it fits your work; unused skills cost almost nothing.

Which Testing skill should I start with?

Start with Playwright E2E. They cover the most common requests in this category; add the rest as your work calls for them.