| name | managing-pytest |
| description | Use when working with Pytest — pytest testing framework management and
analysis. Covers test discovery, fixture analysis, coverage reporting,
marker-based filtering, parametrized test review, plugin management, and
conftest configuration. Use when managing pytest suites, investigating test
failures, reviewing code coverage, or analyzing test performance.
|
| connection_type | pytest |
| preload | false |
Pytest Testing Framework Management Skill
Manage and analyze pytest test suites, coverage, and configurations.
Core Helper Functions
#!/bin/bash
pytest_run() {
local args="${1:-}"
python -m pytest $args --tb=short -q 2>&1
}
pytest_results() {
local report="${1:-report.xml}"
python -c "
import xml.etree.ElementTree as ET
tree = ET.parse('$report')
root = tree.getroot()
import json
print(json.dumps({
'tests': int(root.attrib.get('tests', 0)),
'failures': int(root.attrib.get('failures', 0)),
'errors': int(root.attrib.get('errors', 0)),
'skipped': int(root.attrib.get('skipped', 0)),
'time': float(root.attrib.get('time', 0))
}))
" 2>/dev/null
}
MANDATORY: Discovery-First Pattern
Always discover pytest configuration and test structure before querying specifics.
Phase 1: Discovery
#!/bin/bash
echo "=== Pytest Configuration ==="
if [ -f "pytest.ini" ]; then
cat pytest.ini | head -20
elif [ -f "pyproject.toml" ]; then
grep -A 20 "\[tool.pytest" pyproject.toml | head -20
elif [ -f "setup.cfg" ]; then
grep -A 20 "\[tool:pytest\]" setup.cfg | head -20
fi
echo ""
echo "=== Pytest Version ==="
python -m pytest --version 2>/dev/null
echo ""
echo "=== Test File Summary ==="
find . -name "test_*.py" -o -name "*_test.py" 2>/dev/null | grep -v __pycache__ | wc -l | xargs echo "Total test files:"
find . -name "test_*.py" 2>/dev/null | grep -v __pycache__ | head -15
echo ""
echo "=== Conftest Files ==="
find . -name "conftest.py" 2>/dev/null | grep -v __pycache__ | head -10
echo ""
echo "=== Installed Plugins ==="
python -m pytest --co -q 2>&1 | tail -3
Phase 2: Analysis
#!/bin/bash
echo "=== Test Collection (dry run) ==="
python -m pytest --collect-only -q 2>/dev/null | tail -5
echo ""
echo "=== Markers ==="
python -m pytest --markers 2>/dev/null | head -15
echo ""
echo "=== Coverage Summary ==="
if [ -f "htmlcov/status.json" ]; then
cat htmlcov/status.json | python -c "
import json, sys
d = json.load(sys.stdin)
print(f'Lines: {d.get(\"totals\",{}).get(\"percent_covered_display\",\"N/A\")}%')
" 2>/dev/null
elif [ -f ".coverage" ]; then
python -m coverage report --show-missing 2>/dev/null | tail -10
fi
echo ""
echo "=== Last JUnit Report ==="
REPORT=$(find . -name "report.xml" -o -name "junit.xml" -o -name "test-results.xml" 2>/dev/null | head -1)
if [ -n "$REPORT" ]; then
pytest_results "$REPORT" | python -m json.tool
fi
Output Rules
- TOKEN EFFICIENCY: Target 50 lines per output
- Use
--tb=short or --tb=line for concise failure output
- Parse JUnit XML or JSON reports rather than raw console output
Anti-Hallucination Rules
- NEVER guess test function names — always discover via
--collect-only
- NEVER fabricate coverage numbers — parse actual .coverage or reports
- NEVER assume conftest fixtures — check conftest.py files first
Safety Rules
- NEVER modify test files without explicit user confirmation
- NEVER delete .coverage or htmlcov without user approval
- Be cautious with
--lf (last failed) — it depends on cache state
Output Format
Present results as a structured report:
Managing Pytest Report
══════════════════════
Resources discovered: [count]
Resource Status Key Metric Issues
──────────────────────────────────────────────
[name] [ok/warn] [value] [findings]
Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]
Target ≤50 lines of output. Use tables for multi-resource comparisons.
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "I'll skip discovery and check known resources" | Always run Phase 1 discovery first | Resource names change, new resources appear — assumed names cause errors |
| "The user only asked for a quick check" | Follow the full discovery → analysis flow | Quick checks miss critical issues; structured analysis catches silent failures |
| "Default configuration is probably fine" | Audit configuration explicitly | Defaults often leave logging, security, and optimization features disabled |
| "Metrics aren't needed for this" | Always check relevant metrics when available | API/CLI responses show current state; metrics reveal trends and intermittent issues |
| "I don't have access to that" | Try the command and report the actual error | Assumed permission failures prevent useful investigation; actual errors are informative |