Skip to content

⭐ Testing

Terrence Daniels edited this page Aug 15, 2026 · 6 revisions

Framework: MSTest.Sdk on .NET's newer Microsoft.Testing.Platform (MTP) runner — already pinned in global.json from the original SDK research, not a new choice. MTP is a genuinely different CLI surface from the older VSTest-based dotnet test (its own --help says so directly) — coverage and TRX reporting are both built into the runner itself, confirmed against a real scratch project rather than assumed.

Testing is no longer a separate end-of-migration phase. tests/eShop.ServiceDefaults.UnitTests (26 passing tests) was added and grown before the source migration resumed past IntegrationEventLogEF. Going forward, every project gets its own test project in the same unit of work as its source files — src/Shared/ included, despite not being a .csproj project itself.

Two patterns worth knowing:

  • InternalsVisibleTo for internal classes worth testing directly, rather than reflection (brittle) or skipping coverage — used on OpenApiOptionsExtensions, which is internal end-to-end.
  • NSubstitute (already centrally pinned, upstream's own Ordering.UnitTests uses it too) for behavior only reachable through a DI/HTTP pipeline — HttpClientExtensions's bearer-token-injecting handler is a private nested class, only exercisable through its public AddAuthToken surface plus a mocked IAuthenticationService.

Tracked, not solved: wanted one combined HTML report across every test project; MTP's --report-html produces one file per project instead (confirmed via a real 2-project scratch solution). The real fix (microsoft/testfx#10529) merged 2026-08-09 but hasn't shipped in a NuGet release yet — Dependabot already tracks the package individually, so no new tooling is needed to know when it does.

Full detail in todo.md's "Testing strategy" section and docs/architecturedesign.md Section 11.

Clone this wiki locally