mcp-server-ppt: Instructions file for GitHub Copilot

Testing Strategy - Quick Reference

Test Execution

⚠️ CRITICAL: Always specify the test project explicitly to avoid running all test projects!

A zero-match filter exits 0. A bare dotnet test with a filter that matches nothing prints "No test matches the given testcase filter" and then returns success, so a filter naming a trait that does not exist is indistinguishable from a passing run. Run filtered tests through scripts\Invoke-GuardedTest.ps1, which fails on a zero match. Only the Feature values listed below exist, and scripts\check-test-filters.ps1 enforces that every filter written in the documentation resolves to at least one real test.

Current Feature values: ActionEnums, ActionValidation, Batch, Configuration, Design, Diag, Export, File, FileLocking, Master, McpProtocol, ParameterTransforms, PptBatch, PptMcpService, PptSession, ServiceDaemon, ServiceRegistry, ServiceRouting, SessionManager, SkillGeneration, Slide, StreamJsonRpc, VersionCheck.

Regenerate the list with:

Get-ChildItem -Recurse tests -Include *.cs |
  Select-String -Pattern '\[Trait\("Feature",\s*"([^"]+)"\)' |
  ForEach-Object { $_.Matches[0].Groups[1].Value } | Sort-Object -Unique

A leftover pptcli daemon makes CLI integration tests lie. ServiceFixture hosts a PptMcpService in-process on the CLI pipe name and configures it through in-process test hooks. Windows allows several server instances per pipe name, so a daemon left running by an earlier suite answers the CLI's connection instead - with none of those hooks. The result is ordering-dependent failures that pass on re-run in isolation, which is the most expensive kind. Invoke-GuardedTest.ps1 now stops stray daemons before every run (guard 5) and the fixture refuses to start if the pipe is already served, but if you invoke dotnet test directly, clear them yourself:

Get-Process pptcli -ErrorAction SilentlyContinue | ForEach-Object { Stop-Process -Id $_.Id -Force }