By arcboxlabs
Seven Claude Skills distilled from the canonical software-testing books — make Claude write and review tests well: unit-test craft (Khorikov, Osherove), systematic case derivation (Aniche), test smells & patterns (Meszaros), getting legacy code under test (Feathers), team test strategy (Crispin & Gregory), and the context-driven testing mindset (Kaner, Bach & Pettichord).
Plan a team's test strategy and decide what kinds of testing a product actually needs, using Lisa Crispin and Janet Gregory's "Agile Testing" — the Agile Testing Quadrants, the whole-team approach to quality, and an explicit definition of "done." Use this skill whenever the user asks what kinds of tests they need, how to plan testing for a feature or release, where exploratory / performance / usability / acceptance / security testing fit, who owns quality on a team, what "done" should mean, how to balance manual vs. automated testing, or how to shape a test-automation strategy — even if they never mention the book or Crispin & Gregory. Also for questions like "what should our test strategy be", "do we even need exploratory testing", "what's our definition of done", or "how do we split testing work across the team". This skill is strategy/process advisory — for writing an individual unit test use khorikov-unit-testing / art-of-unit-testing. Enforces: classify testing with the four quadrants; treat quality as a whole-team responsibility; and define "done" explicitly at story and release level.
Write, organize, name, and tame unit tests in the style of Roy Osherove's "The Art of Unit Testing" — trustworthy, maintainable, readable tests built around a unit of work's entry point and exit points. Use this skill whenever the user asks you to write or scaffold unit tests, name or structure a test, choose between a value / state / interaction test, set up or avoid a mocking (isolation) framework, or clean up tests that are brittle, flaky, over-mocked, or unreadable — even if they never mention the book or Osherove. Also use it for questions like "how should I name this test", "why is this test so brittle", "is this a stub or a mock", or "how many asserts per test". Enforces: assert an exit point (observable behavior), never an internal call; never verify a stub; one concern per test with no logic in the test body; and prefer value/state tests over interaction tests.
Think like a skilled tester — investigate, explore, and report bugs that actually get fixed — in the style of Kaner, Bach & Pettichord's "Lessons Learned in Software Testing" (the context-driven school). Use this skill whenever the user asks how to think like a tester, how to do exploratory testing or write a charter, how to design a testing approach for their specific situation, what an oracle or heuristic is, how to write a bug report that gets fixed, whether a testing metric or "best practice" is meaningful, or what manual testing and automation are each good for — even if they never mention the book or its authors. Also for questions like "how should we test this", "is 100% automation realistic", "why isn't this bug getting fixed", or "what makes a good exploratory testing session". This skill is mindset/strategy advisory, not write-this-unit-test (use khorikov-unit-testing / effective-software-testing for that). Enforces: there are no best practices, only practices that fit a context; testing is investigation, not just verification; every oracle is fallible; and a bug report is an advocacy document for the fix.
Systematically derive test cases — and judge how thorough a test suite is — in the style of Maurício Aniche's "Effective Software Testing." This is the "how do I come up with the right inputs" complement to behavior-focused unit testing. Use this skill whenever the user asks what test cases to write, how to cover a function or method, how to find missing edge cases, what to test at a boundary, how to test a complex boolean condition, whether a suite is thorough enough, how to use code coverage well, whether to reach for property-based testing, or how to make a class testable — even if they never mention the book or Aniche. Also for questions like "what inputs should I test here", "is 100% coverage enough", "how do I test all these combinations", or "why is this class so hard to test". Enforces: derive cases from the specification first (partitions + boundaries); use coverage as a guide to find gaps, never as a target; and design for controllability and observability.
Write and review unit tests in the style of Vladimir Khorikov's "Unit Testing Principles, Practices, and Patterns" (the classical/Detroit school). Use this skill whenever the user asks you to write, add, generate, scaffold, fix, refactor, audit, or review unit tests or a test suite — even if they never mention Khorikov or the book — and whenever you are about to write tests as part of a larger coding task. Also use it for questions like "what should I test here", "should I mock this", "why is this test brittle/flaky", "is this a good test", or "how should I structure this test". The skill enforces four rules above all: test OBSERVABLE BEHAVIOR not implementation details; maximize resistance to refactoring (no false failures); mock ONLY unmanaged out-of-process dependencies; and do NOT write tests for trivial code.
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
A collection of Claude Skills distilled from the canonical software-testing books, that
make Claude write and review tests well — one Skill per book, bundled as a plugin.
An optional short testing-rules.md snippet is there too, if you want an always-on
nudge without installing anything.
English | 简体中文
Independent distillation of each book's principles (in our own words). Not affiliated with or endorsed by the authors or publishers. Read the books — they're excellent — for the full treatment.
LLM- and junior-written test suites fail the same predictable ways: they mock every collaborator and assert on the calls, pin down implementation details, mock the database, re-implement the production formula to compute the "expected" value, test trivial getters and setters, pick inputs ad hoc, and chase a coverage number. The result is expensive to maintain, fires false alarms, and discourages the very refactoring tests are supposed to enable.
These skills exist to stop exactly those habits — each from the angle of one canonical book, reconciled into one consistent house style.
testing-canon/
├── skills/ # the product — one Claude Skill per book (the plugin bundles these)
│ ├── khorikov-unit-testing/ # classical-school unit-test craft (the core)
│ ├── art-of-unit-testing/ # trustworthy/maintainable/readable fundamentals
│ ├── effective-software-testing/ # systematic test-case derivation
│ ├── xunit-test-patterns/ # test smells & the patterns that fix them
│ ├── legacy-code-testing/ # get untested code safely under test
│ ├── agile-testing-quadrants/ # whole-team test strategy
│ └── context-driven-testing/ # the investigative tester's mindset
├── testing-rules.md # optional: short drop-in snippet to APPEND to your own CLAUDE.md
├── EXAMPLES.md # worked before/after pairs, per book
├── CLAUDE.md # project/contributor guide (for working on this repo)
└── .claude-plugin/ # marketplace + plugin manifests (bundles all skills)
Each skill is a full progressive-disclosure Skill: a SKILL.md decision workflow plus
focused references/ — installed via the plugin or copied as a folder. If you'd rather
have a lightweight always-on nudge without installing anything, testing-rules.md is a
short snippet you append to your project's CLAUDE.md — a taster, not a replacement for
the skills.
| I want to… | Use |
|---|---|
| Write clean unit tests | khorikov-unit-testing + art-of-unit-testing |
| Figure out which test cases to write (inputs, edge cases, boundaries) | effective-software-testing |
| Fix brittle / flaky / smelly / duplicated tests | xunit-test-patterns |
| Get legacy / untested code safely under test | legacy-code-testing |
| Plan a team's test strategy / decide what kinds of tests are needed | agile-testing-quadrants |
| Think like a tester — exploratory testing, better bug reports | context-driven-testing |
| Just want a short always-on nudge (no install) | append testing-rules.md to your CLAUDE.md |
The skills trigger automatically on the matching task even if you never name the book —
e.g. "write unit tests for this OrderService", "why does this test break on every
refactor", "how do I test this untested class", "what should our test strategy be".
| Skill | Book | Author(s) |
|---|---|---|
khorikov-unit-testing | Unit Testing Principles, Practices, and Patterns | Vladimir Khorikov |
art-of-unit-testing | The Art of Unit Testing | Roy Osherove |
effective-software-testing | Effective Software Testing | Maurício Aniche |
xunit-test-patterns | xUnit Test Patterns | Gerard Meszaros |
legacy-code-testing | Working Effectively with Legacy Code | Michael Feathers |
agile-testing-quadrants | Agile Testing | Lisa Crispin & Janet Gregory |
context-driven-testing | Lessons Learned in Software Testing | Kaner, Bach & Pettichord |
Where they agree (the skills embody this; testing-rules.md is the short always-on version): test observable
behavior, not implementation; mock only at the real boundary (use real objects and
assert on state otherwise); test the code that carries risk and treat coverage as
a guide, not a target; one clear behavior per test, named for the behavior, with no
logic in the test; design for testability by separating decisions from side effects;
and prefer verification styles in the order output > state > communication.
Where they genuinely disagree — left unreconciled, the skills would give Claude whiplash, so the repo picks a house style and each skill notes the alternative and links across:
npx claudepluginhub arcboxlabs/testing-canon --plugin testing-canonComplete collection of battle-tested Claude Code configs from an Anthropic hackathon winner - agents, skills, hooks, and rules evolved over 10+ months of intensive daily use
Comprehensive skill pack with 66 specialized skills for full-stack developers: 12 language experts (Python, TypeScript, Go, Rust, C++, Swift, Kotlin, C#, PHP, Java, SQL, JavaScript), 10 backend frameworks, 6 frontend/mobile, plus infrastructure, DevOps, security, and testing. Features progressive disclosure architecture for 50% faster loading.
Unity Development Toolkit - Expert agents for scripting/refactoring/optimization, script templates, and Agent Skills for Unity C# development
Modern R development skills for Claude Code - tidyverse patterns, rlang metaprogramming, Bayesian inference, performance optimization, and more
Develop, test, build, and deploy Godot 4.x games with Claude Code. Includes GdUnit4 testing, web/desktop exports, CI/CD pipelines, and deployment to Vercel/GitHub Pages/itch.io.
Comprehensive .NET development skills for modern C#, ASP.NET, MAUI, Blazor, Aspire, EF Core, Native AOT, testing, security, performance optimization, CI/CD, and cloud-native applications