Microsoft.Testing.Platform (MTP) now surfaces test failures inline in GitHub Actions and Azure DevOps, preserving evidence when CI runs crash and exposing a stable JSON schema for automation. The update, detailed in the .NET Blog, shifts the focus from producing result files to helping developers decide what to do next.
MTP powers dotnet test, the Test Explorer in Visual Studio and Visual Studio Code, and test runs in CI. Most capabilities in this release require MTP 2.3.0 or later, and the examples were validated with MSTest.Sdk 4.3.3 and MTP 2.3.3. GitHub Actions, JUnit, and CTRF reporters currently ship as preview packages. MTP is supported by MSTest, NUnit, xUnit.net, TUnit, and Expecto, as noted in the Microsoft.Testing.Platform overview.
For GitHub Actions, enabling --report-gh turns a failing test into an annotation on the exact line of code that failed. Skipped tests appear as warnings, and assemblies collapse into their own log groups. The same run writes a summary straight to the workflow page without requiring a report artifact download.
Azure DevOps gets equivalent inline annotations via --report-azdo, plus live streaming of results into the Tests tab while the run is still executing. The central new capability is --report-azdo-flaky-history 14, which queries the past 14 days of pipeline history and labels each failure as [REGRESSION] or [flaky: failed 3/20 in last 14d]. That distinction matters because intermittent failures train reviewers to treat every red build as background noise. The history annotations need a SYSTEM_ACCESSTOKEN to call the Azure DevOps REST API; without it, the run skips history and continues normally.
Crash resilience changed as well. TRX results are now streamed to disk as they are produced, so a hard crash no longer destroys the entire report. Pairing --report-trx with --crashdump produces a valid TRX containing every completed test and a console list of the ones that did not finish, plus a *.crash.sequence.log recording every test start and end.
Output formats serve different consumers. Only TRX and JUnit are parsed by CI systems into a results view; HTML and CTRF serve humans and dashboards, showing up as downloadable artifacts. CTRF uses a shared JSON schema, so .NET reports into the same shape as a polyglot estate. Report names no longer collide either: each reporter accepts --report-<format>-filename with build-specific placeholders such as {asm} and {tfm}, resolved under the results directory.
Automation also gains a stable input. --list-tests json emits a schema-versioned document describing every discovered test down to its source location, which is useful for test selection, impact analysis, or IDE integration instead of scraping console text. In agent or LLM environments, MTP suppresses the banner, ANSI escapes, and progress animation, and defaults --show-stdout and --show-stderr to failed.
Framework support for MTP 2.x arrives in MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0, and xunit.v3 4.0 prereleases, as documented in the testing with dotnet test guidance. Mixing MTP and VSTest projects in one solution is not supported; on the .NET 10 SDK, running an MTP project through the old VSTest path fails the build with a link to the opt-in.
For teams that treat root-cause analysis as a separate discipline, How TReNDS automates root-cause analysis with Amazon Bedrock offers a parallel look at automated diagnostic pipelines, while MTP keeps the investigation inside the test report itself.
