使用pytest的Python测试策略,包括TDD方法、夹具、模拟、参数化和覆盖率要求。
49
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./docs/zh-CN/skills/python-testing/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description does a good job listing specific pytest-related capabilities and testing concepts, making it clear what the skill covers. However, it lacks an explicit 'Use when...' clause, which is critical for Claude to know when to select this skill. Adding trigger guidance and common user-facing synonyms would significantly improve its effectiveness.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about writing Python tests, setting up pytest, test-driven development, or improving test coverage.'
Include common English and natural-language trigger terms users might say, such as 'unit tests', 'test cases', 'test-driven development', 'write tests', 'assert', or '.py test files'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions/concepts: TDD methodology, fixtures, mocking, parameterization, and coverage requirements. These are all concrete, identifiable testing techniques rather than vague abstractions. | 3 / 3 |
Completeness | Clearly answers 'what does this do' (Python testing strategy with pytest including TDD, fixtures, mocking, parameterization, coverage requirements), but lacks an explicit 'Use when...' clause or equivalent trigger guidance, which caps this dimension at 2 per the rubric. | 2 / 3 |
Trigger Term Quality | Includes good keywords like 'pytest', 'Python', 'TDD', 'fixtures', 'mocking', 'parameterization', and 'coverage', but is missing common user variations such as 'unit tests', 'test-driven development', 'test cases', '.py tests', or 'assert'. Also lacks English equivalents which could limit matching in multilingual contexts. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'pytest', 'Python testing', 'TDD', and specific testing techniques like fixtures and parameterization creates a clear niche that is unlikely to conflict with other skills. It is distinctly about Python test strategy with pytest. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive pytest tutorial but fails as a SKILL.md by being excessively verbose and monolithic. It explains many concepts Claude already knows (basic assertions, what TDD means, simple test structure) and packs everything into a single file with no progressive disclosure. Its strength is highly actionable, executable code examples covering a wide range of testing patterns.
Suggestions
Reduce content by 60-70%: remove basic assertions, trivial test examples, and explanations of concepts Claude already knows. Focus only on project-specific conventions and non-obvious patterns.
Split into multiple files: move detailed sections (async testing, mocking patterns, configuration) into separate referenced files like MOCKING.md, ASYNC_TESTING.md, CONFIG.md.
Add a concise quick-reference overview at the top (under 30 lines) that covers the key conventions and decisions, with links to detailed files for each topic.
Add validation/feedback loop guidance: what to do when coverage drops below 80%, how to triage test failures, and when to re-run specific test subsets.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Explains basic pytest concepts Claude already knows (assertions, basic test structure, what TDD is). The basic assertions section alone lists trivial patterns like `assert result == expected`. The entire document reads like a pytest tutorial rather than a concise skill reference. | 1 / 3 |
Actionability | All code examples are executable and copy-paste ready. Concrete commands for running tests, configuration files, and complete fixture/mock patterns are provided with real Python code rather than pseudocode. | 3 / 3 |
Workflow Clarity | The TDD cycle (red-green-refactor) is clearly sequenced, and test organization is well-structured. However, there are no validation checkpoints or feedback loops for the testing workflow itself—e.g., no guidance on what to do when coverage drops below threshold, or how to diagnose and fix failing tests systematically. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. Everything is inlined—basic assertions, advanced mocking, async testing, configuration, and best practices—all in one massive document. Content like the full assertions reference, async testing patterns, and configuration examples should be split into separate files. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (817 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
64cd1ba
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.