test-suit-repair-pattern
Systematically fix failing tests in a test suite — root cause analysis, targeted patches, regression verification, and documentation.
Best use case
test-suit-repair-pattern is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Systematically fix failing tests in a test suite — root cause analysis, targeted patches, regression verification, and documentation.
Teams using test-suit-repair-pattern should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/test-suit-repair-pattern/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How test-suit-repair-pattern Compares
| Feature / Agent | test-suit-repair-pattern | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Systematically fix failing tests in a test suite — root cause analysis, targeted patches, regression verification, and documentation.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Test Suite Repair Pattern When an audit or CI identifies failing tests, follow this pattern to fix them efficiently without introducing regressions. ## When to Use - Test suite has 1-10 failing tests - Audit reports test failures (e.g., Tier-1 repo audit identifying 6 failing tests) - CI pipeline is broken and needs fixing - Tests have stale expectations after code changes ## Phase 1: Triage 1. Run the full test suite to get the exact failure list: ```bash cd <repo> uv run python -m pytest tests/ --noconftest -v 2>&1 | grep FAILED ``` 2. Run each failing test individually to get the full traceback: ```bash uv run python -m pytest tests/path/to/test.py::TestClass::test_name -v 2>&1 | tail -30 ``` 3. Categorize failures: - **Path/fixture issues**: Tests create temp dirs but code uses CWD - **Stale assertions**: Test expects behavior that was never implemented - **Missing methods**: Test calls method that doesn't exist - **Wrong imports**: Test references nonexistent module/class - **Real bugs**: Actual code defect ## Phase 2: Root Cause Analysis For each failure, trace the code path: 1. Read the failing test (what it expects) 2. Read the code path it exercises (what it actually does) 3. Identify the mismatch Common patterns found: - **`agents_base_dir` ignored**: Test passes dir in args dict, but `__init__` initializes components with CWD before `execute()` can override. Fix: pass `base_dir=Path(tmpdir)` to constructor, not in dict. - **Stale YAML fields**: Code writes field `integration: True` but dataclass expects `enabled: True`. Fix both writer and reader. - **Missing method**: Test calls `command.validate_repository()` — method doesn't exist. Fix: replace with actual integration test or implement stub. - **Wrong import path**: Test imports from `cli.manager` but class is in `commands.cli`. Fix import. ## Phase 3: Fix Apply targeted patches: 1. **For path/fixture issues**: Pass correct `base_dir` or `Path(tmpdir)` to constructor 2. **For stale assertions**: Update assertion to match actual implemented behavior, or add `# TODO` comment for unimplemented feature 3. **For missing methods**: Either implement the method OR rewrite the test to use existing API 4. **For wrong imports**: Fix the import path Critical rules: - NEVER change production code to match a broken test — the test is wrong, not the code (unless you've verified it's a real bug) - If a feature isn't implemented, adjust the test expectation, don't implement the feature - When fixing assertions, verify the agent structure/config actually exists rather than checking specific field values ## Phase 4: Verification 1. Run the specific test file to confirm all its tests pass: ```bash uv run python -m pytest tests/path/to/test_file.py -v 2>&1 | tail -10 ``` 2. Run the FULL test suite to verify no regressions: ```bash uv run python -m pytest tests/ --noconftest -q 2>&1 | tail -5 ``` 3. Expected: All pass, 0 failed. Accept: 0 failed (skipped is fine). ## Phase 5: Clean Commit 1. Clean up test artifacts before committing: ```bash # Revert timestamp drifts in test result YAML files git checkout -- tests/modules/*/results/*.yml git checkout -- tests/modules/*/results/*.html git checkout -- tests/modules/**/input_data/*.xlsx # Remove test-generated directories rm -rf agents/ git checkout -- agents/ # if tracked # Verify only real code/test changes remain git status --short ``` 2. Commit with descriptive message: ```bash git commit -m "fix(tests): resolve <N> failing tests — <total> passed 0 failed (#issue) - test_name1: root cause + fix - test_name2: root cause + fix" ``` 3. Push and verify CI. ## Pitfalls 1. **patch tool mangles files with \r\n line endings** — use python3 terminal to edit: ```python with open(path, 'r') as f: content = f.read() content = content.replace(old, new, 1) with open(path, 'w') as f: f.write(content) ``` 2. **Test artifacts in git tree** — running tests creates `agents/` dir and modifies result YAML timestamps. Always `git checkout` these before committing. 3. **Staged accidentally** — `git add -A` will include test artifacts. Stage specific files instead: `git add tests/agent_os/commands/...` 4. **Fixing the wrong layer** — if test passes `agents_base_dir` in execute() dict but components are initialized in `__init__`, setting it in execute() is too late. Pass to constructor instead. 5. **Assuming feature exists** — many tests assert behavior for unimplemented features (config_file loading, custom_structure, type auto-fallback). Adjust assertions, don't implement the feature. ## Example: assetutilities 6-test fix (#1962) Initial state: 6 failed, 1234 passed - 5 tests used `agents_base_dir` dict arg → fix: pass `base_dir=Path(self.temp_dir)` to constructor - 1 test called nonexistent `validate_repository()` → fix: rewrite as execute() integration test - 2 tests had stale assertions for unimplemented features → fix: adjust expectation to match reality Final state: 1235 passed, 9 skipped, 0 failed
Related Skills
test-oversized-skill
A test fixture skill that exceeds 200 lines with multiple H2/H3 sections for split testing.
orcaflex-reporting-fixture-proof-pattern
Build and extend fixture-backed OrcaFlex reporting proof paths in digitalmodel using stable metadata baselines, normalized HTML snapshots, and reusable reporting test helpers.
digitalmodel-worktree-test-execution-with-shared-venv
Run digitalmodel tests from isolated worktrees without uv editable-dependency failures by using the main repo's existing virtualenv and PYTHONPATH.
blender-worktree-test-hardening
Recover and harden digitalmodel Blender automation work in isolated worktrees when uv/editable dependency paths break and local machines lack a Blender executable.
gtm-demo-validation-cache-regression-repair
Diagnose and repair GTM demo validation failures caused by legacy cache files missing intermediate chart data, especially in nested digitalmodel demo scripts using --from-cache.
work-around-merge-conflicts-in-test-execution
Run tests when repo has unresolved merge conflicts in config files by bypassing broken configs and executing tests directly
test-driven-hook-debugging
Debugging and fixing shell hooks by writing isolated test suites first, then using test failures to pinpoint logic bugs
taxact-browser-automation-patterns
Patterns for automating TaxAct Business online (Ionic SPA) via Chrome browser MCP tools — field interaction, navigation, shadow DOM handling
portable-pattern-verification-workflow
Multi-package implementation with verification strategy for cross-platform configuration hardening
portable-config-baseline-pattern
Extract machine-agnostic settings into portable template files while keeping machine-specific hooks and plugins separate
portable-baseline-pattern-implementation
Implement portable configuration baselines by separating machine-agnostic settings from machine-specific hooks and plugins
portable-baseline-pattern-extraction
Extract and separate portable baseline config from machine-specific overrides in multi-environment projects