--- title: Test reporting in Microsoft.Testing.Platform: from red... description: Microsoft.Testing.Platform (MTP) 2.3+ brings significant improvements to test reporting in CI environments. Key features include inline failure annotations in... canonical: https://daily.dev/posts/test-reporting-in-microsoft-testing-platform-from-red-build-to-root-cause-8w2taxpcg twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Test reporting in Microsoft.Testing.Platform: from red build to root cause | daily.dev og:description: Microsoft.Testing.Platform (MTP) 2.3+ brings significant improvements to test reporting in CI environments. Key features include inline failure annotations in... og:url: https://daily.dev/posts/test-reporting-in-microsoft-testing-platform-from-red-build-to-root-cause-8w2taxpcg og:image: https://api.daily.dev/og/posts/8w2tAXPcG.png og:image:alt: Test reporting in Microsoft.Testing.Platform: from red build to root cause og:image:width: 1200 og:image:height: 630 og:locale: en --- [.NET Blog](https://daily.dev/sources/dotnet) [Read post](https://api.daily.dev/r/8w2tAXPcG) # [Test reporting in Microsoft.Testing.Platform: from red build to root cause](https://api.daily.dev/r/8w2tAXPcG "Go to post") 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. [#cicd](/tags/cicd "Check all #cicd posts")[#.net](/tags/.net "Check all #.net posts")[#azure-devops](/tags/azure-devops "Check all #azure-devops posts") Aug 06•12m read time•From [devblogs.microsoft.com](https://api.daily.dev/r/8w2tAXPcG "devblogs.microsoft.com") [](https://api.daily.dev/r/8w2tAXPcG "Go to post") Table of contents [Put the failure where the author is already looking Copy link](https://api.daily.dev/r/8w2tAXPcG?a=put-the-failure-where-the-author-is-already-looking "Put the failure where the author is already looking Copy link")[Azure DevOps: tell a genuine regression from a known flake Copy link](https://api.daily.dev/r/8w2tAXPcG?a=azure-devops:-tell-a-genuine-regression-from-a-known-flake "Azure DevOps: tell a genuine regression from a known flake Copy link")[Keep the evidence when the run crashes Copy link](https://api.daily.dev/r/8w2tAXPcG?a=keep-the-evidence-when-the-run-crashes "Keep the evidence when the run crashes Copy link")[One run, reports for people and tools Copy link](https://api.daily.dev/r/8w2tAXPcG?a=one-run-reports-for-people-and-tools "One run, reports for people and tools Copy link")[Stable output for automation Copy link](https://api.daily.dev/r/8w2tAXPcG?a=stable-output-for-automation "Stable output for automation Copy link")[Try it today Copy link](https://api.daily.dev/r/8w2tAXPcG?a=try-it-today "Try it today Copy link")[Where reporting goes next Copy link](https://api.daily.dev/r/8w2tAXPcG?a=where-reporting-goes-next "Where reporting goes next Copy link") Questions 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 \`\_\_\` pattern to avoid this silently. Developers maintaining multi-target .NET repos catch data-loss bugs like this one on daily.dev. 665 Impressions Comment Bookmark Copy Share your thoughtsPost [](https://daily.dev/sources/dotnet) [.NET Blog](https://daily.dev/sources/dotnet "https://daily.dev/sources/dotnet") dotnet offers insights into .NET development, C# programming language, and cross-platform applicatio... Read more 1.2K Followers • 2.3K Upvotes #### Would you recommend this post? Copy link WhatsApp Facebook X New Squad Copy linkShare with your friends ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Test reporting in Microsoft.Testing.Platform: from red build to root cause","url":"https://daily.dev/posts/test-reporting-in-microsoft-testing-platform-from-red-build-to-root-cause-8w2taxpcg","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/test-reporting-in-microsoft-testing-platform-from-red-build-to-root-cause-8w2taxpcg"},"datePublished":"2026-08-06T17:06:12.051Z","dateModified":"2026-08-06T17:06:46.182Z","description":"Microsoft.Testing.Platform (MTP) 2.3+ brings significant improvements to test reporting in CI environments. Key features include inline failure annotations in...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/581bab1e7495251f987e8e9361426ee1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/581bab1e7495251f987e8e9361426ee1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":".NET Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":".NET Blog","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/f23eb59371bd4f07aeef64c4eef73266","url":"https://daily.dev/sources/dotnet"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/test-reporting-in-microsoft-testing-platform-from-red-build-to-root-cause-8w2taxpcg","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"cicd,.net,azure-devops","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":".NET Blog","item":"https://daily.dev/sources/dotnet"},{"@type":"ListItem","position":3,"name":"Test reporting in Microsoft.Testing.Platform: from red build to root cause"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/test-reporting-in-microsoft-testing-platform-from-red-build-to-root-cause-8w2taxpcg#faq","mainEntity":[{"@type":"Question","name":"How do I distinguish a flaky test from a real regression in Azure DevOps using Microsoft.Testing.Platform?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"How does Microsoft.Testing.Platform preserve test results when the test host crashes mid-run?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"How do I prevent TRX report filename collisions when running dotnet test in a multi-target matrix build?","acceptedAnswer":{"@type":"Answer","text":"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 `__` pattern to avoid this silently. Developers maintaining multi-target .NET repos catch data-loss bugs like this one on daily.dev."}}]} ```