mcp-server-powerpoint testing-strategy.instructions.md

Testing Strategy

Rule 30: real-COM integration tests only. There are no unit tests with mocked COM objects anywhere in this repo's Core test suite — every test that touches Core commands drives a real PowerPoint desktop instance.

Strict TDD (Red → Green)

1. Write a failing test that proves the bug/gap exists (red).
2. Run it, confirm it fails for the expected reason (not a compile error or unrelated failure).
3. Implement the minimal Core/ComInterop change to make it pass (green).
4. Re-run the specific test, then the domain's full Feature= filter, to confirm no regression.

Do not write implementation before a failing test exists for it.

Test Project Layout

tests/
├── PowerPointMcp.Core.Tests/         # Real-COM integration tests, one file per domain
│   ├── xunit.runner.json             # maxParallelThreads: 1
│   ├── ShapeCommandsTests.cs          [Trait("Category","Integration")] [Trait("Feature","Shape")]
│   ├── ChartCommandsTests.cs          [Trait("Feature","Chart")]
│   └── ...
└── PowerPointMcp.McpServer.Tests/     # MCP protocol + session round-trip tests
    ├── xunit.runner.json
    └── Integration/
        ├── McpProtocolTests.cs        # No COM — in-memory transport, schema/wiring assertions
        └── McpRoundTripTests.cs       # Real COM — full open→edit→save→close lifecycle

Serialization Is Mandatory

xunit.runner.json sets maxParallelThreads: 1 in both test projects. PowerPoint does not support multiple concurrent automation sessions launched by parallel test threads reliably — running tests in parallel WILL cause flaky failures or hangs. Never remove or override this setting to "speed up" a local run.

Anti-pattern: using both IClassFixture<T> and [Collection("...")] with a collection fixture on the same test class — dual fixtures can create concurrent Excel/PowerPoint sessions that deadlock during initialization under maxParallelThreads: 1. Use only the collection fixture if a shared fixture is needed.