testing
Testing guidelines. Use when Writing, Editing, or reviewing tests.
When & Why to Use This Skill
This Claude skill provides a comprehensive framework for writing, editing, and reviewing software tests. It focuses on enhancing test reliability and maintainability by enforcing strict assertion patterns, semantic naming conventions that avoid redundancy, and optimized mocking strategies that prefer realistic fakes over complex abstractions.
Use Cases
- Test Suite Auditing: Reviewing existing test files to ensure assertions are strict (e.g., using deep equality) to prevent false positives in CI/CD pipelines.
- Standardizing Test Naming: Refactoring test suites to remove redundant 'test' keywords and improve readability for better developer experience.
- Mocking Strategy Optimization: Guiding developers to use in-memory fakes or network recording tools instead of fragile mocks, ensuring tests are more robust and less coupled to implementation details.
- Code Review Assistance: Automatically checking pull requests to ensure new tests adhere to established organizational testing guidelines and best practices.
| name | testing |
|---|---|
| description | Testing guidelines. Use when Writing, Editing, or reviewing tests. |
Testing Guidelines
Test Naming
- Test names should not include the word "test"
Assertions
- Test assertions should be strict
- Bad:
expect(content).to.include('valid-content') - Better:
expect(content).to.equal({ key: 'valid-content' }) - Best:
expect(content).to.deep.equal({ key: 'valid-content' })
- Bad:
Mocking
- Use mocking as a last resort
- Don't mock a database, if it's possible to use an in-memory fake implementation instead
- Don't mock a larger API if we can mock a smaller API that it delegates to
- Prefer frameworks that record/replay network traffic over mocking
- Don't mock our own code
- Don't overuse the word "mock"
- Mocking means replacing behavior, by replacing method or function bodies, using a mocking framework
- In other cases use the words "fake" or "example"