Microsoft.Testing.Platform (MTP) 2.3+ brings significant improvements to test reporting in CI environments. Key features include inline failure annotations in GitHub Actions and Azure DevOps, live result streaming to Azure DevOps Tests tab during a run, and history-based flaky vs. regression detection using pipeline history. TRX reports are now streamed to disk so a host crash no longer loses all results. Multiple output formats (TRX, HTML, JUnit, CTRF) can be enabled simultaneously, report filenames support build-specific placeholders to avoid collisions in matrix builds, and a JSON test discovery schema provides stable output for automation and IDE tooling. Azure DevOps-specific features include quarantine of known flaky tests, slow-test history detection, and automatic artifact upload. Configuration can be centralized in testconfig.json or Directory.Build.props for repo-wide rollout.
Table of contents
Put the failure where the author is already looking Copy linkAzure DevOps: tell a genuine regression from a known flake Copy linkKeep the evidence when the run crashes Copy linkOne run, reports for people and tools Copy linkStable output for automation Copy linkTry it today Copy linkWhere reporting goes next Copy linkQuestions this post answers
How do I distinguish a flaky test from a real regression in Azure DevOps using Microsoft.Testing.Platform?
Pass `--report-azdo-flaky-history 14` to dotnet test. MTP queries the pipeline's history for the specified number of days and labels each failure: a test that has failed intermittently gets a tag like `[flaky: failed 3/20 in last 14d]`, while a test with no prior failure history is labelled `[REGRESSION]`. Adding `--report-azdo-demote-known-flaky` downgrades known-flaky failures to warnings so only regressions block the build. Teams shipping .NET services track flaky-vs-regression signals like these on daily.dev.
How does Microsoft.Testing.Platform preserve test results when the test host crashes mid-run?
TRX results are streamed to disk as each test completes rather than serialized at the end. Running `dotnet test --report-trx --crashdump` adds a controller process that finalises the partial report when the host dies. The output is a valid TRX containing every completed test, a console list of tests still running at crash time, and a `*.crash.sequence.log` recording every test start and end for unambiguous identification of the culprit. Developers debugging hard-to-reproduce crashes in .NET test suites follow tooling updates like this on daily.dev.
How do I prevent TRX report filename collisions when running dotnet test in a multi-target matrix build?
Use the `--report-trx-filename` option with build-specific placeholders such as `{asm}` and `{tfm}`. For example: `dotnet test --report-trx --report-trx-filename "reports/{asm}_{tfm}_{time}.trx"`. Without this, multi-targeted projects targeting both `net8.0` and `net8.0-windows` overwrite each other's reports. MTP 2.3+ defaults TRX, HTML, and JUnit filenames to a deterministic `<asm>_<tfm>_<arch>` pattern to avoid this silently. Developers maintaining multi-target .NET repos catch data-loss bugs like this one on daily.dev.