test-design-reviewer
Scores test quality based on Dave Farley's testing principles to ensure your test suite acts as an effective safety net.
Install
mkdir -p .claude/skills/test-design-reviewer && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4977" && unzip -o skill.zip -d .claude/skills/test-design-reviewer && rm skill.zipInstalls to .claude/skills/test-design-reviewer
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Evaluates test quality using Dave Farley's 8 properties. Use when reviewing tests, assessing test suite quality, or analyzing test effectiveness against TDD best practices.Key capabilities
- →Scores test design across 8 properties
- →Grades readability and intent
- →Analyzes coupling to implementation details
- →Provides recommendations for test refactoring
How it works
Evaluates code against predefined heuristics for the 8 properties of good tests (e.g., atomic, repeatable), returning a score and specific refactoring advice.
Inputs & outputs
When to use test-design-reviewer
- →Reviewing legacy test suites for brittleness
- →Analyzing test effectiveness against TDD standards
- →Refactoring tests to improve readability
- →Scoring new tests for project compliance
About this skill
Test Design Reviewer
Review tests as executable specifications and safety evidence. Read the tests before the implementation so their public story can stand on its own, then inspect the production boundary and repository constraints needed to judge the claims accurately.
Properties
| Property | Inspect | Strong evidence |
|---|---|---|
| Understandable | Names, arrange/act/assert flow, domain vocabulary | The behavior and failure are clear without reconstructing internals |
| Maintainable | Coupling, duplication, fixtures, public boundaries | Behavior-preserving refactors do not require unrelated test rewrites |
| Repeatable | Time, randomness, concurrency, network, shared resources | Repeated and parallel runs have controlled inputs and cleanup |
| Atomic | Shared state, ordering, cleanup, failure isolation | A test can run alone and its failure identifies one behavior |
| Necessary | Distinct risk or contract protected | Removing the test would remove meaningful evidence |
| Granular | Scope of behavior and diagnostic quality | Assertions describe one coherent outcome; related assertions may stay together |
| Fast | Measured feedback time at the appropriate layer | The suite is fast enough for its intended feedback loop |
| First | Evidence of test-first development | A captured RED run, development trace, or history demonstrates the test failed for the expected reason before production behavior changed |
Rating
Rate each property Strong, Mixed, Weak, or Not assessed.
- Use exact file locations and observed evidence.
- Do not calculate an aggregate score; unequal risks and repository contexts make a weighted number falsely precise.
- Mark First
Not assessedwhen only the final tree is available. Static test shape cannot prove chronology. - Mark Fast
Not assessedunless execution evidence or trustworthy timing is available. - Prefer the smallest change that strengthens observable behavior. Do not demand one assertion per test, one test per file, or unit tests where a higher-level contract is the honest evidence boundary.
Review Process
- Establish the claimed behavior, test layer, repository policy, and relevant risk.
- Read the tests without implementation and record what a failure would mean.
- Inspect the public production boundary, fixtures, and configured runner.
- Run focused tests or timing only when authorized and useful; report exactly what ran.
- Rate every property with evidence, including
Not assessedwhere evidence is absent. - Rank only actionable findings by severity and impact. Include the smallest credible fix.
- Separate test defects from production-design seams and local policy preferences.
Output
## Test design review: [scope]
| Property | Rating | Evidence |
|---|---|---|
| Understandable | Strong/Mixed/Weak/Not assessed | [file:line and reason] |
| Maintainable | ... | ... |
| Repeatable | ... | ... |
| Atomic | ... | ... |
| Necessary | ... | ... |
| Granular | ... | ... |
| Fast | ... | ... |
| First | ... | ... |
### Findings
1. **[severity] — [problem]** (`path:line`)
Impact: [observable risk].
Smallest fix: [action].
### Validation gaps
- [Anything not assessed and the evidence needed]
No findings is a valid result; do not invent work to populate the section.
Source And Attribution
The eight properties are drawn from Dave Farley's
Properties of Good Tests.
This version is a fresh, evidence-based implementation rather than a textual
adaptation of an external skill. Read
references/source-notes.md for the exact
historical provenance and unresolved permission issue in older releases.
When not to use it
- →When writing throwaway code
- →When the codebase lacks sufficient test coverage to analyze
Limitations
- →Subjective grading based on agent interpretation of test intent
- →Does not automate the actual refactoring, only provides instructions
How it compares
Applies explicit academic testing principles rather than relying on standard code-linting or coverage metrics.
Compared to similar skills
test-design-reviewer side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| test-design-reviewer (this skill) | 1 | 2mo | No flags | Intermediate |
| python-testing-patterns | 77 | 2mo | Review | Intermediate |
| dependency-upgrade | 26 | 5mo | Review | Intermediate |
| test-cases | 57 | 7mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by citypaul
View all by citypaul →You might also like
python-testing-patterns
wshobson
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development. Use when writing Python tests, setting up test suites, or implementing testing best practices.
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
test-cases
cexll
This skill should be used when generating comprehensive test cases from PRD documents or user requirements. Triggers when users request test case generation, QA planning, test scenario creation, or need structured test documentation. Produces detailed test cases covering functional, edge case, error handling, and state transition scenarios.
reviewing-code
CaptainCrouton89
Systematically evaluate code changes for security, correctness, performance, and spec alignment. Use when reviewing PRs, assessing code quality, or verifying implementation against requirements.
wcag-audit-patterns
wshobson
Conduct WCAG 2.2 accessibility audits with automated testing, manual verification, and remediation guidance. Use when auditing websites for accessibility, fixing WCAG violations, or implementing accessible design patterns.
code-coverage-with-gcov
gadievron
Add gcov code coverage instrumentation to C/C++ projects