
Code Testing
ALWAYS USE for test work that requires changes: write, add, generate, repair, or...
Install
npx skills add managedcode/dotnet-skills --skill code-testing -g -a claude-code -y- Repository
- managedcode/dotnet-skills500
- Category
- Design
- Updated
- 6d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
ALWAYS USE for test work that requires changes: write, add, generate, repair, or strengthen tests for existing code in xUnit, MSTest, NUnit, pytest, Vitest/Jest, Go, or another framework. Includes regression cases, failing or flaky tests, coverage-driven additions, and audit-then-fix requests. Focused work stays direct; broad or multi-stage work invokes test-engineer. DO NOT USE for only running tests, analysis-only audits, framework/platform migrations, a test blocked on a missing production seam (testability-obstacle), or MSTest API/configuration corrections that do not design new cases (writing-mstest-tests). Within an active test-engineer pipeline, reuse supplied guidance and do not re-enter this skill.
Code Testing Skill
The reliable implicit entry point for generating, repairing, and strengthening
tests. It handles focused work directly and invokes the public test-engineer
agent for broad or multi-stage requests.
Non-negotiable execution contract
Check pipeline ownership first. If the active agent is
test-engineer (including a plugin-qualified name such as
dotnet-test:test-engineer), or the caller assigned you a phase of
that pipeline, do not delegate to another generator. Continue the assigned
work inline. This guard takes precedence over every broad-scope delegation
instruction below, even if this skill was loaded automatically.
Classify scope before editing:
- Broad (a project/package-wide suite, or multiple production
files/modules): create
research.mdandplan.mdin a resolved non-stageable<TESTAGENT_DIR>before implementation, thenstatus.mdthere after the final test-quality review. Whentest-engineeris available, invoke that named custom agent before implementing; do not replace it with a generic subagent carrying the same label or implement the broad request inline. If the state files are absent, the broad workflow is incomplete. - Focused (the user explicitly limits work to one function/class/file or one missing method): do not create intermediate state files or fan out to multiple agents. A sparse project-wide request remains broad even when only one source module is present.


