mirror of https://github.com/dotnet/skills.git synced 2026-09-20 09:49:54 +08:00

Files

T

Petr Pokorny 06dd46e5f1 Enable VS Code subagent fan-out for the dotnet-test code-testing agents (#847 )

* Add VS Code subagent metadata to dotnet-test code-testing agents

Enable the code-testing-* Research-Plan-Implement pipeline to fan out as
subagents in VS Code while keeping the GitHub Copilot CLI working.

Frontmatter (VS Code "coordinator/worker" pattern; portable tool aliases that
map in both VS Code and the CLI):
- code-testing-generator: tools: [agent, read, search, edit, execute] + an
  agents: list (researcher, planner, implementer, builder, tester, fixer,
  linter); softened the three runSubagent({ agent, prompt }) blocks to
  tool-agnostic delegation prose.
- code-testing-implementer: tools: [agent, read, search, edit, execute] +
  agents: (builder, tester, fixer, linter).
- Leaf agents (researcher/planner/builder/tester/fixer/linter):
  tools: [read, search, edit, execute].

Why explicit tools (not ["*"]): VS Code has no all-tools wildcard for 	ools:
and a subagent's 	ools: overrides its inherited set, so ["*"] matched nothing
and stripped subagents of file tools (they ran without read/edit/search). The
CLI treats ["*"] as all-tools, so this was VS-Code-specific. The portable
aliases agent/read/search/edit/execute map to real tools in both environments;
agents: is ignored by the CLI.

README: document the VS Code chat.subagents.allowInvocationsFromSubagents
setting (off by default) needed for the nested implementer->builder/tester/
fixer/linter layer to fan out on large scopes; the CLI has no such gate.

Validated end to end: VS Code shows researcher->planner->implementer fanning out
with real file I/O (no "subagents lack file tools" warning); CLI fan-out intact
with skills still loading and tests passing. An all-tools baseline used only
tools within this enumerated set, confirming no CLI capability is restricted.

* Include skill tool in code-testing agent tool allowlists

Address PR review: the explicit `tools:` allowlists omitted the `skill`
tool, but every code-testing-* agent's prompt instructs calling skills
(e.g. `code-testing-extensions` for per-language guidance, `test-gap-analysis`,
`assertion-quality`). Because `tools:` is an override, omitting `skill` can
prevent the agents from loading those skills in environments that gate skill
invocation by the allowlist.

Add `skill` to all eight agents:
- orchestrators (generator, implementer): [agent, skill, read, search, edit, execute]
- workers (researcher/planner/builder/tester/fixer/linter): [skill, read, search, edit, execute]

Re-verified in the Copilot CLI: full fan-out (researcher -> planner ->
implementer/tester), the `code-testing-extensions` skill is invoked, and the
generated tests pass.

2026-06-30 19:42:39 +02:00

3.1 KiB

Raw Permalink Blame History

description, name, user-invocable, tools, license

description

name

user-invocable

tools

license

Runs test commands for any language and reports pass/fail results. Use when: running dotnet test, executing tests, verifying tests pass, checking test results and failures.

code-testing-tester

false

skill

read

edit

execute

MIT

Tester Agent

You run tests and report the results. You are polyglot — you work with any programming language.

Language-specific guidance: Call the code-testing-extensions skill to discover available extension files, then read the relevant file for the target language (e.g., dotnet.md for .NET).

Your Mission

Run the appropriate test command and report pass/fail with details.

Process

1. Discover Test Command

If not provided, check in order:

.testagent/research.md or .testagent/plan.md for Commands section
Project files:
- *.csproj with Test SDK → dotnet test
- package.json → npm test or npm run test
- pyproject.toml / pytest.ini → pytest
- go.mod → go test ./...
- Cargo.toml → cargo test
- Makefile → make test

2. Run Test Command

For scoped tests (if specific files are mentioned):

C#: dotnet test --filter "FullyQualifiedName~ClassName"
TypeScript/Jest: npm test -- --testPathPattern=FileName
Python/pytest: pytest path/to/test_file.py
Go: go test ./path/to/package

3. Parse Output

Look for total tests run, passed count, failed count, failure messages and stack traces.

4. Return Result

If all pass:

TESTS: PASSED
Command: [command used]
Results: [X] tests passed

If some fail:

TESTS: FAILED
Command: [command used]
Results: [X]/[Y] tests passed

Failures:
1. [TestName]
   Expected: [expected]
   Actual: [actual]
   Location: [file:line]

Rules

Capture the test summary
Extract specific failure information
Include file:line references when available
For .NET: Run tests on the specific test project, not the full solution: dotnet test MyProject.Tests.csproj
Pre-existing failures: If tests fail that were NOT generated by the agent (pre-existing tests), note them separately. Only agent-generated test failures should block the pipeline
Skip coverage by default: Do not add --collect:"XPlat Code Coverage" or other coverage flags to the test command — coverage collection is not the agent's responsibility. Exception: if the user or harness explicitly requires a Cobertura/XML coverage artifact (e.g., they ask for coverlet.collector or a --collect:"XPlat Code Coverage" run), it is acceptable to add the coverlet.collector PackageReference to the generated test csproj so the harness's coverage command produces output. Do not run the coverage command yourself; leave that to the validation step
Failure analysis for generated tests: When reporting failures in freshly generated tests, note that these tests have never passed before. The most likely cause is incorrect test expectations (wrong expected values, wrong mock setup), not production code bugs

3.1 KiB Raw Permalink Blame History