From f8f04c732228dc7a0d9420fe77c775256c3147b1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Tue, 3 Mar 2026 15:10:11 +0100 Subject: [PATCH 1/8] Follow-up on test platforms docs refactoring --- ...esting-platform-architecture-extensions.md | 4 +- ...ng-platform-architecture-test-framework.md | 44 +++---------------- ...sting-platform-extensions-vstest-bridge.md | 7 ++- .../microsoft-testing-platform-fakes.md | 2 +- .../microsoft-testing-platform-features.md | 2 +- .../microsoft-testing-platform-retry.md | 2 +- ...microsoft-testing-platform-test-reports.md | 5 ++- ...rosoft-testing-platform-troubleshooting.md | 2 +- docs/core/testing/test-platforms-overview.md | 13 +++--- 9 files changed, 29 insertions(+), 52 deletions(-) diff --git a/docs/core/testing/microsoft-testing-platform-architecture-extensions.md b/docs/core/testing/microsoft-testing-platform-architecture-extensions.md index 08d0e0020a942..bd2be77f07da5 100644 --- a/docs/core/testing/microsoft-testing-platform-architecture-extensions.md +++ b/docs/core/testing/microsoft-testing-platform-architecture-extensions.md @@ -7,13 +7,13 @@ ms.date: 02/24/2026 ai-usage: ai-assisted --- -# Build extensions +# Build extensions for Microsoft.Testing.Platform This article covers the extensibility points for Microsoft.Testing.Platform beyond the test framework itself. For test framework creation, see [Build a test framework](./microsoft-testing-platform-architecture-test-framework.md). For the full extension point summary and in-process/out-of-process concepts, see [Create custom extensions](./microsoft-testing-platform-architecture.md). -## Other extensibility points +## Extensibility points The testing platform provides additional extensibility points that allow you to customize the behavior of the platform and the test framework. These extensibility points are optional and can be used to enhance the testing experience. diff --git a/docs/core/testing/microsoft-testing-platform-architecture-test-framework.md b/docs/core/testing/microsoft-testing-platform-architecture-test-framework.md index 2e6d46c49905e..c49caef48deb2 100644 --- a/docs/core/testing/microsoft-testing-platform-architecture-test-framework.md +++ b/docs/core/testing/microsoft-testing-platform-architecture-test-framework.md @@ -13,7 +13,7 @@ This article explains how to create a custom test framework for Microsoft.Testin For the full extension point summary and in-process/out-of-process concepts, see [Create custom extensions](./microsoft-testing-platform-architecture.md). -If you're migrating an existing VSTest-based test framework to Microsoft.Testing.Platform, use the [VSTest Bridge](./microsoft-testing-platform-extensions-vstest-bridge.md) extension to simplify the transition. +If you're migrating an existing VSTest-based test framework, implementing the `ITestFramework` interface natively is the recommended approach. The [VSTest Bridge](./microsoft-testing-platform-extensions-vstest-bridge.md) extension is available as a transitional step, but a native implementation provides the best experience. ## Test framework extension @@ -103,33 +103,19 @@ The `ITestFramework` interface inherits from the `IExtension` interface, which i #### The `CreateTestSessionAsync` method -The `CreateTestSessionAsync` method is called at the start of the test session and is used to initialize the test framework. The API accepts a `CloseTestSessionContext` object and returns a `CloseTestSessionResult`. +The `CreateTestSessionAsync` method is called at the start of the test session and is used to initialize the test framework. The API accepts a `CreateTestSessionContext` object and returns a `CreateTestSessionResult`. ```csharp public sealed class CreateTestSessionContext : TestSessionContext { - public SessionUid SessionUid { get; } - public ClientInfo Client { get; } public CancellationToken CancellationToken { get; } } - -public readonly struct SessionUid -{ - public string Value { get; } -} - -public sealed class ClientInfo -{ - public string Id { get; } - public string Version { get; } -} ``` -The `SessionUid` serves as the unique identifier for the current test session, providing a logical connection to the session's results. -The `ClientInfo` provides details about the entity invoking the test framework. This information can be utilized by the test framework to modify its behavior. For example, as of the time this document was written, a console execution would report a client name such as "testingplatform-console". +The `SessionUid` property is inherited from `TestSessionContext` (see the [TestSessionContext section](#testsessioncontext)). The `CancellationToken` is used to halt the execution of `CreateTestSessionAsync`. -The return object is a `CloseTestSessionResult`: +The return object is a `CreateTestSessionResult`: ```csharp public sealed class CreateTestSessionResult @@ -204,32 +190,22 @@ The `TestSessionContext` is a shared property across all requests, providing inf public class TestSessionContext { public SessionUid SessionUid { get; } - public ClientInfo Client { get; } } public readonly struct SessionUid(string value) { public string Value { get; } } - -public sealed class ClientInfo -{ - public string Id { get; } - public string Version { get; } -} ``` -The `TestSessionContext` consists of the `SessionUid`, a unique identifier for the ongoing test session that aids in logging and correlating test session data. It also includes the `ClientInfo` type, which provides details about the *initiator* of the test session. The test framework may choose different routes or publish varying information based on the identity of the test session's *initiator*. +The `TestSessionContext` consists of the `SessionUid`, a unique identifier for the ongoing test session that aids in logging and correlating test session data. #### DiscoverTestExecutionRequest ```csharp public class DiscoverTestExecutionRequest { - // Detailed in the custom section below public TestSessionContext Session { get; } - - // This is experimental and intended for future use, please disregard for now. public ITestExecutionFilter Filter { get; } } ``` @@ -261,10 +237,7 @@ await context.MessageBus.PublishAsync( ```csharp public class RunTestExecutionRequest { - // Detailed in the custom section below public TestSessionContext Session { get; } - - // This is experimental and intended for future use, please disregard for now. public ITestExecutionFilter Filter { get; } } ``` @@ -360,7 +333,7 @@ public class TestNode public PropertyBag Properties { get; init; } = new(); } -public sealed class TestNodeUid(string value) +public sealed class TestNodeUid(string value); public sealed partial class PropertyBag { @@ -499,10 +472,7 @@ public sealed record TestMethodIdentifierProperty( string ReturnTypeFullName) ``` -`TestMethodIdentifierProperty` is a unique identifier for a test method, adhering to the ECMA-335 standard. - -> [!NOTE] -> The data needed to create this property can be conveniently obtained using the .NET reflection feature, using types from the `System.Reflection` namespace. +`TestMethodIdentifierProperty` is a unique identifier for a test method. ```csharp public sealed record TestMetadataProperty( diff --git a/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md b/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md index 0fb519002fa79..50e7a9f0db4ec 100644 --- a/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md +++ b/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md @@ -8,7 +8,12 @@ ms.date: 04/10/2024 # VSTest Bridge extension -This extension provides a compatibility layer with VSTest allowing the test frameworks depending on it to continue supporting running in VSTest mode (`vstest.console.exe`, `dotnet test`, `VSTest task` on Azure DevOps, Test Explorers of Visual Studio and Visual Studio Code). This extension is shipped as part of [Microsoft.Testing.Extensions.VSTestBridge](https://nuget.org/packages/Microsoft.Testing.Extensions.VSTestBridge) NuGet package. +This extension provides a compatibility layer with VSTest allowing test frameworks that are already implemented with VSTest to: + +1. Run easily with Microsoft.Testing.Platform without a major rewrite. +2. Support both VSTest and Microsoft.Testing.Platform with the same test framework implementation. + +This extension is shipped as part of [Microsoft.Testing.Extensions.VSTestBridge](https://nuget.org/packages/Microsoft.Testing.Extensions.VSTestBridge) NuGet package. ## Compatibility with VSTest diff --git a/docs/core/testing/microsoft-testing-platform-fakes.md b/docs/core/testing/microsoft-testing-platform-fakes.md index 7a3c3e5ec67bb..71566940746ea 100644 --- a/docs/core/testing/microsoft-testing-platform-fakes.md +++ b/docs/core/testing/microsoft-testing-platform-fakes.md @@ -1,5 +1,5 @@ --- -title: Microsoft.Testing.Platform Microsoft Fakes +title: Microsoft Fakes support for Microsoft.Testing.Platform description: Learn about the Microsoft.Testing.Platform Fakes extension capabilities and how to use it. author: drognanar ms.author: arturs diff --git a/docs/core/testing/microsoft-testing-platform-features.md b/docs/core/testing/microsoft-testing-platform-features.md index e836d3aeefaad..a806f7036a35d 100644 --- a/docs/core/testing/microsoft-testing-platform-features.md +++ b/docs/core/testing/microsoft-testing-platform-features.md @@ -35,7 +35,7 @@ Use the following path based on your goal: - Need hot reload support: [Hot Reload](./microsoft-testing-platform-hot-reload.md) (extension) - Need Microsoft Fakes support: [Microsoft Fakes](./microsoft-testing-platform-fakes.md) (extension) - Need OpenTelemetry traces and metrics: [OpenTelemetry](./microsoft-testing-platform-open-telemetry.md) (extension) -- Need telemetry opt-out information: [Telemetry](./microsoft-testing-platform-telemetry.md) (extension) +- Telemetry data collection and opt-out: [Telemetry](./microsoft-testing-platform-telemetry.md) (extension) ## Built-in features diff --git a/docs/core/testing/microsoft-testing-platform-retry.md b/docs/core/testing/microsoft-testing-platform-retry.md index 94cfbceaaec89..ad38673caa127 100644 --- a/docs/core/testing/microsoft-testing-platform-retry.md +++ b/docs/core/testing/microsoft-testing-platform-retry.md @@ -18,7 +18,7 @@ This feature requires the [Microsoft.Testing.Extensions.Retry](https://nuget.org ```csharp var builder = await TestApplication.CreateBuilderAsync(args); -builder.TestHost.AddRetryProvider(); +builder.AddRetryProvider(); ``` ## Retry diff --git a/docs/core/testing/microsoft-testing-platform-test-reports.md b/docs/core/testing/microsoft-testing-platform-test-reports.md index 3aafbbf1c55d1..070108b99de9b 100644 --- a/docs/core/testing/microsoft-testing-platform-test-reports.md +++ b/docs/core/testing/microsoft-testing-platform-test-reports.md @@ -25,12 +25,15 @@ var builder = await TestApplication.CreateBuilderAsync(args); builder.AddTrxReportProvider(); ``` +> [!NOTE] +> When using manual registration, register the TRX report provider last. The current implementation depends on registration order, so registering it after all other extensions ensures it captures all test data. + ### Options | Option | Description | |---|---| | `--report-trx` | Generates the TRX report. | -| `--report-trx-filename` | The name of the generated TRX report. The default name matches the following format `__.trx`. | +| `--report-trx-filename` | The name of the generated TRX report. The default name matches the following format `__.trx`. | The report is saved inside the default _TestResults_ folder that can be specified through the `--results-directory` command line argument. diff --git a/docs/core/testing/microsoft-testing-platform-troubleshooting.md b/docs/core/testing/microsoft-testing-platform-troubleshooting.md index d7341dc88f550..495069419b861 100644 --- a/docs/core/testing/microsoft-testing-platform-troubleshooting.md +++ b/docs/core/testing/microsoft-testing-platform-troubleshooting.md @@ -22,7 +22,7 @@ This article contains troubleshooting guidance for `Microsoft.Testing.Platform`. | `2` | An exit code of `2` is used to indicate that there was at least one test failure. | | `3` | The exit code `3` indicates that the test session was aborted. A session can be aborted using Ctrl+C, as an example. | | `4` | The exit code `4` indicates that the setup of used extensions is invalid and the tests session cannot run. | -| `5` | The exit code `5` indicates that the command line arguments passed to the test app are invalid. | +| ~~`5`~~ | ~~The exit code `5` indicated that the command line arguments passed to the test app were invalid.~~ This exit code is no longer produced by the platform. | | `6` | The exit code `6` indicates that the test session is using a non-implemented feature. | | `7` | The exit code `7` indicates that a test session was unable to complete successfully, and likely crashed. It's possible that this was caused by a test session that was run via a test controller's extension point. | | `8` | The exit code `8` indicates that the test session ran zero tests. | diff --git a/docs/core/testing/test-platforms-overview.md b/docs/core/testing/test-platforms-overview.md index 2ab093dda05c3..709eee75c04a0 100644 --- a/docs/core/testing/test-platforms-overview.md +++ b/docs/core/testing/test-platforms-overview.md @@ -19,10 +19,8 @@ You can choose between two test platforms: - **VSTest** - **Microsoft.Testing.Platform (MTP)** -> [!WARNING] -> Don't mix VSTest and Microsoft.Testing.Platform test projects in the same repository run configuration. -> -> Choose one platform for your repository test workflow, and configure test projects, CI, and tooling consistently for that platform. +> [!TIP] +> For the simplest setup, choose one platform for your repository and configure test projects, CI, and tooling consistently for that platform. Mixing VSTest and MTP test projects in the same run configuration is possible (for example, using MTP for .NET tests and VSTest for C++ or JavaScript tests), but requires careful configuration. ## How to choose your platform @@ -31,13 +29,14 @@ Use the following scenarios to choose quickly. | Use case | Choose | Why | |---|---|---| | You need Native AOT or trimming test execution scenarios. | Microsoft.Testing.Platform | MTP supports these modern deployment scenarios, while VSTest doesn't. | +| You're building WinUI (packaged) or UWP test projects. | VSTest | These project types aren't currently supported by MTP. | | You need to mix .NET tests and non-.NET test adapters (for example JavaScript or C++ adapters). | VSTest | VSTest supports mixed-language adapter scenarios, while MTP is .NET-specific. | | You want test projects to behave like regular executables (`dotnet run`, direct executable run, `dotnet watch`, and startup-project F5 flows). | Microsoft.Testing.Platform | MTP is executable-first, so test apps run like standard .NET apps in local and CI workflows. | -| You rely on long-established integrations across Microsoft and non-Microsoft tooling. | VSTest | VSTest has the longest compatibility track record across existing products, tasks, and pipelines. | +| You rely on long-established integrations across existing tooling. | VSTest | VSTest has the longest compatibility track record across existing products, tasks, and pipelines. MTP support is growing in the ecosystem, but some integrations may lag behind VSTest. | | You prioritize reproducibility and tighter control of extension loading across machines. | Microsoft.Testing.Platform | MTP favors explicit, build-time extension registration, which reduces machine-dependent behavior from dynamically discovered components and can simplify security review. | | You need a minimal core with optional features that you can disable per environment. | Microsoft.Testing.Platform | MTP uses a lightweight core with opt-in extensions. If an extension introduces unsupported dependencies or version conflicts in a specific environment, you can remove or disable that extension. | | You prefer strict defaults and explicit behavior. | Microsoft.Testing.Platform | MTP favors deterministic execution with explicit checks. For example, it can fail when no tests run, reduce environment-dependent variability, and avoid implicit discovery and execution heuristics. | -| You prefer softer, broad backward-compatible defaults. | VSTest | VSTest prioritizes compatibility-oriented defaults for diverse, existing toolchains. | +| You prefer softer, broad backward-compatible defaults. | VSTest | Both platforms care about backward compatibility. VSTest prioritizes compatibility-oriented defaults for diverse, existing toolchains, while MTP provides backward compatibility within its own extension model. | | You are blocked by a VSTest-specific issue or behavior in your current workflow. | Microsoft.Testing.Platform | In many scenarios, the same workflow isn't affected when moved to MTP because of differences in runtime model and extension architecture. | If your specific use case isn't listed, both platforms are valid choices. @@ -48,7 +47,7 @@ If your specific use case isn't listed, both platforms are valid choices. |---|---|---| | IDE integration | Mature integration across Visual Studio and other tools that depend on VSTest protocol and adapters. | Supported in Visual Studio and Visual Studio Code scenarios, with ongoing integration work in parts of the ecosystem. | | CI and external tools | Broad support across long-established Microsoft and non-Microsoft tools and tasks. In Azure DevOps, you can use either the VSTest task (`VSTest@3`, `vstest.console`) or the .NET task (`DotNetCoreCLI@2`, `dotnet test`). | Works in CI and modern .NET workflows, but some third-party integrations might still lag behind VSTest. In Azure DevOps, use the .NET task (`DotNetCoreCLI@2`, `dotnet test`). | -| `dotnet test` behavior | Default VSTest mode. VSTest arguments and behavior apply. | Native MTP mode is available in .NET 10 SDK and later. Before .NET 10 SDK, MTP ran through VSTest mode with limitations (`TestingPlatformDotnetTestSupport`, plus the extra `--` argument separator). | +| `dotnet test` behavior | Default VSTest mode. VSTest arguments and behavior apply. | Native MTP mode is available in .NET 10 SDK and later. | For complete details about `dotnet test` modes and arguments, see [Testing with `dotnet test`](./unit-testing-with-dotnet-test.md). From cb5dd36c89c54b0eb8ad80412db0d5e8f9895a9e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Tue, 3 Mar 2026 16:17:02 +0100 Subject: [PATCH 2/8] Update docs/core/testing/microsoft-testing-platform-troubleshooting.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/core/testing/microsoft-testing-platform-troubleshooting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/microsoft-testing-platform-troubleshooting.md b/docs/core/testing/microsoft-testing-platform-troubleshooting.md index 495069419b861..f4d903d2d85cf 100644 --- a/docs/core/testing/microsoft-testing-platform-troubleshooting.md +++ b/docs/core/testing/microsoft-testing-platform-troubleshooting.md @@ -22,7 +22,7 @@ This article contains troubleshooting guidance for `Microsoft.Testing.Platform`. | `2` | An exit code of `2` is used to indicate that there was at least one test failure. | | `3` | The exit code `3` indicates that the test session was aborted. A session can be aborted using Ctrl+C, as an example. | | `4` | The exit code `4` indicates that the setup of used extensions is invalid and the tests session cannot run. | -| ~~`5`~~ | ~~The exit code `5` indicated that the command line arguments passed to the test app were invalid.~~ This exit code is no longer produced by the platform. | +| `5` (no longer used) | Exit code `5` is no longer produced by the platform; it previously indicated that the command-line arguments passed to the test app were invalid. | | `6` | The exit code `6` indicates that the test session is using a non-implemented feature. | | `7` | The exit code `7` indicates that a test session was unable to complete successfully, and likely crashed. It's possible that this was caused by a test session that was run via a test controller's extension point. | | `8` | The exit code `8` indicates that the test session ran zero tests. | From 0611729160899d8a0902c626ad5771c835264837 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Tue, 3 Mar 2026 16:17:11 +0100 Subject: [PATCH 3/8] Update docs/core/testing/test-platforms-overview.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/core/testing/test-platforms-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/test-platforms-overview.md b/docs/core/testing/test-platforms-overview.md index 709eee75c04a0..461f374feeeac 100644 --- a/docs/core/testing/test-platforms-overview.md +++ b/docs/core/testing/test-platforms-overview.md @@ -20,7 +20,7 @@ You can choose between two test platforms: - **Microsoft.Testing.Platform (MTP)** > [!TIP] -> For the simplest setup, choose one platform for your repository and configure test projects, CI, and tooling consistently for that platform. Mixing VSTest and MTP test projects in the same run configuration is possible (for example, using MTP for .NET tests and VSTest for C++ or JavaScript tests), but requires careful configuration. +> For the simplest setup, choose one platform for your repository, and configure test projects, CI, and tooling consistently for that platform. Don't mix VSTest-based and Microsoft.Testing.Platform-based .NET test projects in the same solution or run configuration because that scenario isn't supported. If you also run non-.NET tests that depend on VSTest (for example, C++ or JavaScript tests), run those tests in separate configurations from your MTP-based .NET tests. ## How to choose your platform From 591f0792b8b0042a0a10b2434926609e7e3954f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Tue, 3 Mar 2026 16:17:40 +0100 Subject: [PATCH 4/8] Apply suggestion from @Evangelink --- .../microsoft-testing-platform-extensions-vstest-bridge.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md b/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md index 50e7a9f0db4ec..b154e54f22394 100644 --- a/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md +++ b/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md @@ -11,7 +11,7 @@ ms.date: 04/10/2024 This extension provides a compatibility layer with VSTest allowing test frameworks that are already implemented with VSTest to: 1. Run easily with Microsoft.Testing.Platform without a major rewrite. -2. Support both VSTest and Microsoft.Testing.Platform with the same test framework implementation. +1. Support both VSTest and Microsoft.Testing.Platform with the same test framework implementation. This extension is shipped as part of [Microsoft.Testing.Extensions.VSTestBridge](https://nuget.org/packages/Microsoft.Testing.Extensions.VSTestBridge) NuGet package. From a51a9baf0c99d2eba4b278ca137900b023d93290 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Wed, 4 Mar 2026 10:17:54 +0100 Subject: [PATCH 5/8] Update docs/core/testing/test-platforms-overview.md Co-authored-by: Youssef Victor --- docs/core/testing/test-platforms-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/test-platforms-overview.md b/docs/core/testing/test-platforms-overview.md index 461f374feeeac..aa3acd06b128e 100644 --- a/docs/core/testing/test-platforms-overview.md +++ b/docs/core/testing/test-platforms-overview.md @@ -29,7 +29,7 @@ Use the following scenarios to choose quickly. | Use case | Choose | Why | |---|---|---| | You need Native AOT or trimming test execution scenarios. | Microsoft.Testing.Platform | MTP supports these modern deployment scenarios, while VSTest doesn't. | -| You're building WinUI (packaged) or UWP test projects. | VSTest | These project types aren't currently supported by MTP. | +| You're building packaged WinUI or UWP test projects. | VSTest | These project types aren't currently supported by MTP. | | You need to mix .NET tests and non-.NET test adapters (for example JavaScript or C++ adapters). | VSTest | VSTest supports mixed-language adapter scenarios, while MTP is .NET-specific. | | You want test projects to behave like regular executables (`dotnet run`, direct executable run, `dotnet watch`, and startup-project F5 flows). | Microsoft.Testing.Platform | MTP is executable-first, so test apps run like standard .NET apps in local and CI workflows. | | You rely on long-established integrations across existing tooling. | VSTest | VSTest has the longest compatibility track record across existing products, tasks, and pipelines. MTP support is growing in the ecosystem, but some integrations may lag behind VSTest. | From a5f04e8a6ada938e997e86464cc1c4be1fc7f326 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Wed, 4 Mar 2026 13:21:50 +0100 Subject: [PATCH 6/8] Fix --- .../testing/microsoft-testing-platform-troubleshooting.md | 4 ++-- docs/core/testing/test-platforms-overview.md | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/core/testing/microsoft-testing-platform-troubleshooting.md b/docs/core/testing/microsoft-testing-platform-troubleshooting.md index f4d903d2d85cf..4e8038c414717 100644 --- a/docs/core/testing/microsoft-testing-platform-troubleshooting.md +++ b/docs/core/testing/microsoft-testing-platform-troubleshooting.md @@ -22,8 +22,8 @@ This article contains troubleshooting guidance for `Microsoft.Testing.Platform`. | `2` | An exit code of `2` is used to indicate that there was at least one test failure. | | `3` | The exit code `3` indicates that the test session was aborted. A session can be aborted using Ctrl+C, as an example. | | `4` | The exit code `4` indicates that the setup of used extensions is invalid and the tests session cannot run. | -| `5` (no longer used) | Exit code `5` is no longer produced by the platform; it previously indicated that the command-line arguments passed to the test app were invalid. | -| `6` | The exit code `6` indicates that the test session is using a non-implemented feature. | +| `5` | The exit code `5` indicates that the command-line arguments passed to the test app were invalid. | +| `6` (no longer used) | Exit code `6` is no longer produced by the platform; it previously indicated that the test session was using a non-implemented feature. | | `7` | The exit code `7` indicates that a test session was unable to complete successfully, and likely crashed. It's possible that this was caused by a test session that was run via a test controller's extension point. | | `8` | The exit code `8` indicates that the test session ran zero tests. | | `9` | The exit code `9` indicates that the minimum execution policy for the executed tests was violated. | diff --git a/docs/core/testing/test-platforms-overview.md b/docs/core/testing/test-platforms-overview.md index aa3acd06b128e..5abb6bf9258c9 100644 --- a/docs/core/testing/test-platforms-overview.md +++ b/docs/core/testing/test-platforms-overview.md @@ -33,9 +33,8 @@ Use the following scenarios to choose quickly. | You need to mix .NET tests and non-.NET test adapters (for example JavaScript or C++ adapters). | VSTest | VSTest supports mixed-language adapter scenarios, while MTP is .NET-specific. | | You want test projects to behave like regular executables (`dotnet run`, direct executable run, `dotnet watch`, and startup-project F5 flows). | Microsoft.Testing.Platform | MTP is executable-first, so test apps run like standard .NET apps in local and CI workflows. | | You rely on long-established integrations across existing tooling. | VSTest | VSTest has the longest compatibility track record across existing products, tasks, and pipelines. MTP support is growing in the ecosystem, but some integrations may lag behind VSTest. | -| You prioritize reproducibility and tighter control of extension loading across machines. | Microsoft.Testing.Platform | MTP favors explicit, build-time extension registration, which reduces machine-dependent behavior from dynamically discovered components and can simplify security review. | | You need a minimal core with optional features that you can disable per environment. | Microsoft.Testing.Platform | MTP uses a lightweight core with opt-in extensions. If an extension introduces unsupported dependencies or version conflicts in a specific environment, you can remove or disable that extension. | -| You prefer strict defaults and explicit behavior. | Microsoft.Testing.Platform | MTP favors deterministic execution with explicit checks. For example, it can fail when no tests run, reduce environment-dependent variability, and avoid implicit discovery and execution heuristics. | +| You prefer strict defaults and explicit behavior. | Microsoft.Testing.Platform | MTP favors deterministic execution with explicit checks and build-time extension registration. For example, it can fail when no tests run, reduce environment-dependent variability, and avoid implicit discovery and execution heuristics. | | You prefer softer, broad backward-compatible defaults. | VSTest | Both platforms care about backward compatibility. VSTest prioritizes compatibility-oriented defaults for diverse, existing toolchains, while MTP provides backward compatibility within its own extension model. | | You are blocked by a VSTest-specific issue or behavior in your current workflow. | Microsoft.Testing.Platform | In many scenarios, the same workflow isn't affected when moved to MTP because of differences in runtime model and extension architecture. | From 818a7f5c76b4a2d1dce5f20a90bd60319b13d536 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Wed, 4 Mar 2026 15:12:35 +0100 Subject: [PATCH 7/8] Merge the 2 rows --- docs/core/testing/test-platforms-overview.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/core/testing/test-platforms-overview.md b/docs/core/testing/test-platforms-overview.md index 5abb6bf9258c9..640ca81f0ff03 100644 --- a/docs/core/testing/test-platforms-overview.md +++ b/docs/core/testing/test-platforms-overview.md @@ -33,8 +33,7 @@ Use the following scenarios to choose quickly. | You need to mix .NET tests and non-.NET test adapters (for example JavaScript or C++ adapters). | VSTest | VSTest supports mixed-language adapter scenarios, while MTP is .NET-specific. | | You want test projects to behave like regular executables (`dotnet run`, direct executable run, `dotnet watch`, and startup-project F5 flows). | Microsoft.Testing.Platform | MTP is executable-first, so test apps run like standard .NET apps in local and CI workflows. | | You rely on long-established integrations across existing tooling. | VSTest | VSTest has the longest compatibility track record across existing products, tasks, and pipelines. MTP support is growing in the ecosystem, but some integrations may lag behind VSTest. | -| You need a minimal core with optional features that you can disable per environment. | Microsoft.Testing.Platform | MTP uses a lightweight core with opt-in extensions. If an extension introduces unsupported dependencies or version conflicts in a specific environment, you can remove or disable that extension. | -| You prefer strict defaults and explicit behavior. | Microsoft.Testing.Platform | MTP favors deterministic execution with explicit checks and build-time extension registration. For example, it can fail when no tests run, reduce environment-dependent variability, and avoid implicit discovery and execution heuristics. | +| You prefer strict defaults and explicit behavior. | Microsoft.Testing.Platform | MTP favors deterministic execution with a lightweight, opt-in extension model and build-time registration. For example, it can fail when no tests run, reduce environment-dependent variability, and let you disable individual extensions per environment. | | You prefer softer, broad backward-compatible defaults. | VSTest | Both platforms care about backward compatibility. VSTest prioritizes compatibility-oriented defaults for diverse, existing toolchains, while MTP provides backward compatibility within its own extension model. | | You are blocked by a VSTest-specific issue or behavior in your current workflow. | Microsoft.Testing.Platform | In many scenarios, the same workflow isn't affected when moved to MTP because of differences in runtime model and extension architecture. | From 858712169113ce54e450acb42351eb7ba34c3dde Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Amaury=20Lev=C3=A9?= Date: Wed, 4 Mar 2026 15:13:41 +0100 Subject: [PATCH 8/8] Fix link --- .../microsoft-testing-platform-architecture-extensions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/microsoft-testing-platform-architecture-extensions.md b/docs/core/testing/microsoft-testing-platform-architecture-extensions.md index bd2be77f07da5..2bd64e57a0b7e 100644 --- a/docs/core/testing/microsoft-testing-platform-architecture-extensions.md +++ b/docs/core/testing/microsoft-testing-platform-architecture-extensions.md @@ -552,7 +552,7 @@ public interface IAsyncCleanableExtension ### The CompositeExtensionFactory -As outlined in the [extensions](#other-extensibility-points) section, the testing platform enables you to implement interfaces to incorporate custom extensions both in and out of process. +As outlined in the [extensions](#extensibility-points) section, the testing platform enables you to implement interfaces to incorporate custom extensions both in and out of process. Each interface addresses a particular feature, and according to .NET design, you implement this interface in a specific object. You can register the extension itself using the specific registration API `AddXXX` from the `TestHost` or `TestHostController` object from the `ITestApplicationBuilder` as detailed in the corresponding sections.