mirror of
https://github.com/dotnet/skills.git
synced 2026-09-20 09:49:54 +08:00
460a01882f
* fix: validate native Codex plugin support Separate Codex-compatible plugin components from GitHub Copilot custom agents, validate Codex manifest fields and MCP shapes, and document the native agent installation boundary. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: strengthen Codex plugin verification Validate Codex MCP per-tool settings and add a pinned native smoke lane that installs the marketplace, discovers skills and MCP, and calls binlog_overview. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: avoid restarting Codex MCP smoke client Use the real tool call as the app-server initialization so the Linux smoke test does not start and tear down a redundant status client first. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: harden Codex validation and smoke cleanup Constrain smoke artifacts to a dedicated child directory, validate Codex manifest field shapes and required skill paths, and document the separate Agents SDK handoff model. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: align Codex smoke and hooks parsing Use the clean Codex installation's default provider for the direct MCP call and reject heterogeneous hooks arrays like the runtime parser. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: verify every Codex plugin skill Compare native skill discovery with the full repository inventory, match Codex lexical path rejection, and allow null optional MCP tool settings. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: address Codex compatibility review Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
163 lines
12 KiB
Markdown
163 lines
12 KiB
Markdown
# dotnet-test
|
||
|
||
Skills and GitHub Copilot custom agents for running, generating, analyzing, and improving tests. Originally built for .NET (MSTest, xUnit, NUnit, TUnit) and platforms (VSTest, Microsoft.Testing.Platform); the test-generation pipeline and the six test-analysis skills (anti-patterns, smells, assertion quality, gap analysis, tagging, grade tests) plus the `test-quality-auditor` agent are **polyglot** and also work with Python (pytest/unittest), TypeScript/JavaScript (Jest/Vitest/Mocha/Jasmine/node:test), Java (JUnit 4/5/TestNG), Go (testing/testify), Ruby (RSpec/Minitest), Rust (built-in/proptest), Swift (XCTest/Swift Testing), Kotlin (JUnit/Kotest), PowerShell (Pester), and C++ (GoogleTest/Catch2/doctest/Boost.Test).
|
||
|
||
> **Test framework/platform migration** (MSTest/xUnit upgrades, xUnit → MSTest, VSTest → Microsoft.Testing.Platform) lives in the separate [`dotnet-test-migration`](../dotnet-test-migration/) plugin.
|
||
|
||
## When to use this plugin
|
||
|
||
- **Run tests** *(.NET only)* — execute SDK-style projects with `dotnet test`, or preserve a classic project's checked-in MSBuild + VSTest/MSTest command
|
||
- **Generate tests** *(polyglot)* — scaffold comprehensive unit tests for any language via a multi-agent pipeline
|
||
- **Migrate tests** *(.NET only)* — see the separate [`dotnet-test-migration`](../dotnet-test-migration/) plugin (MSTest v1/v2 → v3 → v4, xUnit v2 → v3, xUnit → MSTest, VSTest → Microsoft.Testing.Platform)
|
||
- **Audit test quality** *(polyglot)* — detect anti-patterns, test smells, assertion gaps, and (for .NET) coverage risks
|
||
- **Improve testability** *(.NET only)* — find static dependencies, generate wrappers, and migrate call sites to injectable abstractions
|
||
- **Measure coverage** *(.NET only)* — collect code coverage, compute CRAP scores, and surface risk hotspots
|
||
|
||
## Skills
|
||
|
||
### Test execution
|
||
|
||
| Skill | Description |
|
||
|---|---|
|
||
| **run-tests** | Run .NET tests with project-system/platform/framework detection, including classic non-SDK runner commands |
|
||
| **mtp-hot-reload** | Rapid test-fix iteration using MTP hot reload (edit code → re-run without rebuilding) |
|
||
|
||
### Test generation
|
||
|
||
| Skill | Description |
|
||
|---|---|
|
||
| **code-testing-agent** | Multi-agent pipeline (Research → Plan → Implement → Build → Test → Fix → Lint) that generates tests for any language |
|
||
| **scaffold-dotnet-test-project** *(.NET)* | Create a missing test project or repair its project/solution/filter wiring |
|
||
| **writing-mstest-tests** | Version-compatible MSTest authoring for modern and classic projects, including MSTest 3.x/4.x APIs |
|
||
|
||
### Test migration
|
||
|
||
Moved to the [`dotnet-test-migration`](../dotnet-test-migration/) plugin (`migrate-mstest-v1v2-to-v3`, `migrate-mstest-v3-to-v4`, `migrate-xunit-to-xunit-v3`, `migrate-xunit-to-mstest`, `migrate-vstest-to-mtp`, and the `test-migration` orchestrator agent).
|
||
|
||
### Test quality & analysis *(polyglot)*
|
||
|
||
These six skills are all polyglot. They work across all supported languages by loading a per-language reference file from `test-analysis-extensions`. `grade-tests` additionally embeds its own scoring rubric (sub-grades, weighting, anti-pattern catalog) so the per-test grades stay consistent across calls.
|
||
|
||
| Skill | Description |
|
||
|---|---|
|
||
| **test-anti-patterns** | Quick pragmatic scan for common test quality issues with severity ranking (any language) |
|
||
| **test-smell-detection** | Deep formal audit using academic test smell taxonomy (19 smell types, any language) |
|
||
| **assertion-quality** | Measure assertion variety and depth — find shallow tests that barely verify anything (any language) |
|
||
| **test-gap-analysis** | Verify test blind spots through pseudo-mutations and optionally add focused tests that kill them (any language) |
|
||
| **test-tagging** | Tag tests with standardized traits (smoke, regression, boundary, critical-path, etc.); auto-edits where the framework has canonical syntax, report-only otherwise |
|
||
| **grade-tests** | Grade a curated list of test methods individually and produce a compact, PR-comment-friendly table of letter grades (A–F), score bands, and one-line notes — designed for per-PR test-quality feedback (any language) |
|
||
|
||
### Coverage & risk *(.NET only)*
|
||
|
||
| Skill | Description |
|
||
|---|---|
|
||
| **coverage-analysis** | Project-wide code coverage collection with CRAP score computation and risk hotspot reporting |
|
||
| **crap-score** | Calculate CRAP (Change Risk Anti-Patterns) scores for individual methods, classes, or files |
|
||
|
||
For non-.NET languages, use the native coverage tool: `coverage.py`/`pytest-cov` (Python), `jest --coverage`/`c8`/`nyc`/`vitest --coverage` (JS/TS), JaCoCo (Java), `go test -coverprofile` (Go), SimpleCov (Ruby), `cargo-tarpaulin`/`cargo-llvm-cov` (Rust), `xcrun llvm-cov` (Swift), Kover (Kotlin), Pester's built-in code coverage (PowerShell), `gcov`/`llvm-cov` (C++).
|
||
|
||
### Testability improvement *(.NET only)*
|
||
|
||
| Skill | Description |
|
||
|---|---|
|
||
| **detect-static-dependencies** | Scan C# code for hard-to-test statics (DateTime.Now, File.*, HttpClient, etc.) |
|
||
| **generate-testability-wrappers** | Generate wrapper interfaces or guide adoption of built-in abstractions (TimeProvider, IFileSystem) |
|
||
| **migrate-static-to-wrapper** | Bulk-replace static call sites with injected wrapper calls and add constructor injection |
|
||
| **testability-obstacle** | Resolve one concrete ambient-dependency blocker and test the behavior through fixed/in-memory dependencies |
|
||
|
||
### Detection and reference data
|
||
|
||
| Skill | Description |
|
||
|---|---|
|
||
| **code-testing-extensions** | Language-specific guidance loaded by the code-testing pipeline (test generation) |
|
||
| **test-analysis-extensions** | Language-specific guidance loaded by the polyglot analysis skills (test markers, assertion APIs, sleeps, skips, mystery-guest indicators, integration markers, tag-support capability) |
|
||
| **platform-detection** *(.NET)* | Directly detect SDK-style vs classic, VSTest vs MTP, and the test framework from project files |
|
||
| **filter-syntax** *(.NET)* | Test filter syntax reference for VSTest and MTP across all frameworks |
|
||
|
||
Three reference skills (`code-testing-extensions`, `test-analysis-extensions`,
|
||
and `filter-syntax`) set `disable-model-invocation: true`, so the CLI keeps them
|
||
out of the model-facing skill menu and a consumer loads them by name. They
|
||
deliberately have no direct `tests/dotnet-test/<skill>/eval.yaml`: the
|
||
experiment's skilled arm loads a single skill, which the model could never
|
||
invoke here, so such an eval would compare two identical arms and score judge
|
||
noise. They are measured through consumer outcomes — the polyglot analysis
|
||
skills and `grade-tests` for `test-analysis-extensions`, `code-testing-agent`
|
||
for `code-testing-extensions`, and `run-tests` and `mtp-hot-reload` for
|
||
`filter-syntax`. The `run-tests` eval covers VSTest expressions, MTP argument
|
||
passing, xUnit v3 native filters, and TUnit tree-node filters.
|
||
|
||
`platform-detection` is model-invocable because identifying a project's runner
|
||
is also a direct user task; `run-tests` and migration skills still load it as
|
||
shared detection guidance. Its command-mode rules use an on-demand reference so
|
||
platform/framework-only requests do not load or echo CLI-mode detail.
|
||
`filter-syntax` remains reference-only and is measured through the
|
||
filtered-command scenarios in the `run-tests` eval.
|
||
|
||
## Agents
|
||
|
||
The agents below are GitHub Copilot `.agent.md` definitions. Codex plugin installs expose this
|
||
plugin's skills, but not these agents or their static handoffs.
|
||
|
||
### User-facing agents
|
||
|
||
These are the entry-point agents you invoke directly:
|
||
|
||
| Agent | Purpose |
|
||
|---|---|
|
||
| **test-quality-auditor** | Runs multi-skill audit pipelines for comprehensive test suite assessment |
|
||
| **testability-migration** | End-to-end testability improvement: detect → generate wrappers → migrate call sites → add deterministic tests when requested |
|
||
|
||
> **Test framework/platform migration** is handled by the `test-migration` agent in the separate [`dotnet-test-migration`](../dotnet-test-migration/) plugin.
|
||
|
||
### Internal subagents
|
||
|
||
These are pipeline stages invoked automatically by the agents above (`user-invocable: false`). You do not need to call them directly:
|
||
|
||
| Agent | Called by | Purpose |
|
||
|---|---|---|
|
||
| **code-testing-generator** | code-testing-agent skill | Orchestrates the full test generation pipeline (research → plan → implement → build → test → fix → lint) |
|
||
| **code-testing-researcher** | code-testing-generator | Analyzes codebase structure, testing patterns, and testability |
|
||
| **code-testing-planner** | code-testing-generator | Creates phased test implementation plans from research findings |
|
||
| **code-testing-implementer** | code-testing-generator | Implements one phase from the plan, runs build-test-fix cycles |
|
||
| **code-testing-builder** | code-testing-implementer | Runs build/compile commands and reports results |
|
||
| **code-testing-tester** | code-testing-implementer | Runs test commands and reports pass/fail results |
|
||
| **code-testing-fixer** | code-testing-implementer | Fixes compilation errors in source or test files |
|
||
| **code-testing-linter** | code-testing-implementer | Runs code formatting and linting |
|
||
|
||
> **VS Code — enabling full multi-level fan-out:** The pipeline delegates in two levels: `code-testing-generator` → researcher / planner / implementer, and `code-testing-implementer` → builder / tester / fixer / linter. VS Code gates *nested* delegation (a subagent spawning its own subagents) behind a setting that is **off by default**, so the first level runs out of the box but the second one does not. For large scopes — many files or modules, where parallel build/test/fix/lint workers help — enable it in your VS Code settings:
|
||
>
|
||
> ```jsonc
|
||
> "chat.subagents.allowInvocationsFromSubagents": true
|
||
> ```
|
||
>
|
||
> Without it, `code-testing-implementer` still builds, tests, fixes, and lints — it just does that work inline instead of delegating to the worker subagents, so results are unaffected. The GitHub Copilot CLI has no such gate and always fans out.
|
||
|
||
## Prerequisites
|
||
|
||
### For polyglot skills and agents
|
||
|
||
The test-generation pipeline (`code-testing-generator` and friends) and the six test-analysis skills (`test-anti-patterns`, `test-smell-detection`, `assertion-quality`, `test-gap-analysis`, `test-tagging`, `grade-tests`) plus the `test-quality-auditor` agent work with any of the supported languages above. You just need a working test runtime for the language you're targeting (e.g., `python` + `pytest`, `node` + `npm test`, `mvn` / `gradle`, `go`, `bundle exec rspec`, `cargo test`, `swift test`, `pwsh` + Pester, `cmake` + your C++ test runner). The skills will detect the framework automatically.
|
||
|
||
### For .NET-only skills and agents
|
||
|
||
- .NET SDK installed (`dotnet` on PATH)
|
||
- A project with an existing test framework (MSTest, xUnit, NUnit, or TUnit) for execution, migration, coverage, CRAP, testability, and the experimental `dotnet-experimental` skills.
|
||
|
||
### Classic non-SDK .NET projects
|
||
|
||
The test-generation and analysis heuristics support classic projects with
|
||
`packages.config`, explicit `<Compile Include>` items, older MSTest/Moq stacks,
|
||
and custom base fixtures. Generation preserves those conventions and registers
|
||
every new test file in the project.
|
||
|
||
Execution requires the repository's existing Windows/Visual Studio toolchain
|
||
(commonly full MSBuild plus `vstest.console.exe` or `MSTest.exe`). Coverage and
|
||
CRAP analysis accept existing Cobertura reports; they do not inject SDK-style
|
||
coverage packages into classic projects. If the required runner or coverage
|
||
workflow is absent, the skill reports the limitation rather than migrating the
|
||
project.
|
||
|
||
Testability wrappers and migrations are separate, explicit opt-in workflows.
|
||
Test generation and quality audits do not introduce production seams, and all
|
||
testability workflows must honor repository rules that prohibit such refactors.
|