Review Testing
Review test code for quality, design, and completeness after implementing a feature or...
Install
npx skills add posit-dev/skills --skill review-testing -g -a claude-code -y- Repository
- posit-dev/skills551
- Category
- Design
- Updated
- 7d ago
- License
- MIT
- Context cost
- Mediumabout 2,446 tokens
- Runs scripts
- No, instructions only
What it does
Review test code for quality, design, and completeness after implementing a feature or fixing a bug. Use when the user asks to "review my tests", "check my test quality", "are these tests good enough", "review testing", or after completing a feature implementation that includes tests. Also use when tests feel brittle, flaky, or superficial. Cross-references production code to find coverage gaps.
You are reviewing test code written alongside a feature implementation or bug fix. Ensure the tests are well-designed, thorough, and maintainable, not just that they pass. Tests that merely mirror implementation details create false confidence and become a maintenance burden during refactoring.
Review Scope
Identify what to review:
- Find changed test files on the current branch (relative to the base branch).
- Find the production code those tests cover, trace imports, function calls, and file naming conventions to map tests to their targets.
- Find related existing tests for the same modules or functions that weren't changed, these may need updates or reveal gaps.
Read test files first, before production code. If you can infer the feature's requirements and edge cases from the tests alone, that's a sign the tests are well-written. If you need to read the implementation to understand what the tests are doing, that's a finding worth reporting.
What Makes a Test Valuable
Weigh each test against four qualities:
Regression protection, Does this test actually catch bugs? A test that exercises trivial code or skips complex branches protects against nothing. Check: does the test touch business-critical logic, or only verify the happy path of a simple getter?
Refactoring resilience, Will this test break when someone restructures code without changing behavior? Tests coupled to internal method names, call sequences, or private state punish every cleanup with false failures, eroding trust in the suite.
Fast feedback, Unit tests should run in milliseconds. If a test hits the filesystem, network, or database unnecessarily, that's a design issue. But don't confuse speed with value, an integration test verifying a real database query is better than a fast unit test that mocks everything and verifies nothing.
