testing-canon

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.