diff --git a/.openpublishing.redirection.core.json b/.openpublishing.redirection.core.json
index 67c81ecc3ddbb..4d1f3492d6642 100644
--- a/.openpublishing.redirection.core.json
+++ b/.openpublishing.redirection.core.json
@@ -1357,6 +1357,94 @@
{
"source_path_from_root": "/docs/core/docker/publish-as-container.md",
"redirect_url": "/dotnet/core/containers/sdk-publish"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-architecture-capabilities.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-architecture-capabilities"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-architecture-extensions.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-architecture-extensions"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-architecture-services.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-architecture-services"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-architecture.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-architecture"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-config.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-config"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-diagnostics.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-diagnostics"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-exit-codes.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-exit-codes"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-code-coverage.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-code-coverage"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-diagnostics.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-diagnostics"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-fakes.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-fakes"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-faq.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-faq"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-hosting.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-hosting"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-output.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-output"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-policy.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-policy"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-test-reports.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-test-reports"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-vstest-bridge.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-vstest-bridge"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-extensions-faq.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-extensions-faq"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-integration-dotnet-test.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-integration-dotnet-test"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-intro.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-intro"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-telemetry.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-telemetry"
+ },
+ {
+ "source_path_from_root": "/docs/core/testing/unit-testing-platform-vs-vstest.md",
+ "redirect_url": "/dotnet/core/testing/microsoft-testing-platform-vs-vstest"
}
]
}
diff --git a/docs/core/project-sdk/msbuild-props.md b/docs/core/project-sdk/msbuild-props.md
index 95acc8b1ba0e8..bf74a4743916b 100644
--- a/docs/core/project-sdk/msbuild-props.md
+++ b/docs/core/project-sdk/msbuild-props.md
@@ -1476,7 +1476,7 @@ When your project references the [Microsoft.Testing.Platform.MSBuild](https://ww
- Generates the configuration file.
- Detects the extensions.
-Setting the property to `false` disables the transitive dependency to the package. A *transitive dependency* is when a project that references another project that references a given package behaves as if *it* references the package. You'd typically set this property to `false` in a non-test project that references a test project. For more information, see [error CS8892](../testing/unit-testing-platform-faq.md#error-cs8892-method-testingplatformentrypointmainstring-will-not-be-used-as-an-entry-point-because-a-synchronous-entry-point-programmainstring-was-found).
+Setting the property to `false` disables the transitive dependency to the package. A *transitive dependency* is when a project that references another project that references a given package behaves as if *it* references the package. You'd typically set this property to `false` in a non-test project that references a test project. For more information, see [error CS8892](../testing/microsoft-testing-platform-faq.md#error-cs8892-method-testingplatformentrypointmainstring-will-not-be-used-as-an-entry-point-because-a-synchronous-entry-point-programmainstring-was-found).
If your test project references MSTest, NUnit, or xUnit, this property is set to the same value as [EnableMSTestRunner](#enablemstestrunner), [EnableNUnitRunner](#enablenunitrunner), or `UseMicrosoftTestingPlatformRunner` (for xUnit).
@@ -1515,7 +1515,7 @@ The `EnableNUnitRunner` property enables or disables the use of the [NUnit runne
Setting the `GenerateTestingPlatformEntryPoint` property to `false` disables the automatic generation of the program entry point in an MSTest or NUnit test project. You might want to set this property to `false` when you manually define an entry point, or when you reference a test project from an executable that also has an entry point.
-For more information, see [error CS8892](../testing/unit-testing-platform-faq.md#error-cs8892-method-testingplatformentrypointmainstring-will-not-be-used-as-an-entry-point-because-a-synchronous-entry-point-programmainstring-was-found).
+For more information, see [error CS8892](../testing/microsoft-testing-platform-faq.md#error-cs8892-method-testingplatformentrypointmainstring-will-not-be-used-as-an-entry-point-because-a-synchronous-entry-point-programmainstring-was-found).
To control the generation of the entry point in a VSTest project, use the `GenerateProgramFile` property.
@@ -1523,7 +1523,7 @@ To control the generation of the entry point in a VSTest project, use the `Gener
The `TestingPlatformCaptureOutput` property controls whether all console output that a test executable writes is captured and hidden from the user when you use `dotnet test` to run `Microsoft.Testing.Platform` tests. By default, the console output is hidden. This output includes the banner, version information, and formatted test information. Set this property to `false` to show this information together with MSBuild output.
-For more information, see [Show complete platform output](../testing/unit-testing-platform-integration-dotnet-test.md#show-complete-platform-output).
+For more information, see [Show complete platform output](../testing/microsoft-testing-platform-integration-dotnet-test.md#show-complete-platform-output).
### TestingPlatformCommandLineArguments
diff --git a/docs/core/testing/index.md b/docs/core/testing/index.md
index e3f1b6babdc96..cc44ab68ebf77 100644
--- a/docs/core/testing/index.md
+++ b/docs/core/testing/index.md
@@ -41,7 +41,7 @@ When running tests in .NET, there are two components involved: the test platform
The test platform is the engine that runs the tests and acts as a communication channel with IDEs. For example, Visual Studio can send a discovery request to the test platform so that it can display the available tests in Test Explorer. The test platform responds back to the IDE with the tests it found. Similar communication happens for test execution.
-VSTest has been used for many years in .NET and was the only test platform in the ecosystem. Early in 2024, the first stable version of a new test platform, called [Microsoft.Testing.Platform (MTP)](./unit-testing-platform-intro.md), was released.
+VSTest has been used for many years in .NET and was the only test platform in the ecosystem. Early in 2024, the first stable version of a new test platform, called [Microsoft.Testing.Platform (MTP)](./microsoft-testing-platform-intro.md), was released.
### Test frameworks
diff --git a/docs/core/testing/unit-testing-platform-architecture-capabilities.md b/docs/core/testing/microsoft-testing-platform-architecture-capabilities.md
similarity index 83%
rename from docs/core/testing/unit-testing-platform-architecture-capabilities.md
rename to docs/core/testing/microsoft-testing-platform-architecture-capabilities.md
index a0fc4629e45b7..8c3e7557857d7 100644
--- a/docs/core/testing/unit-testing-platform-architecture-capabilities.md
+++ b/docs/core/testing/microsoft-testing-platform-architecture-capabilities.md
@@ -54,7 +54,7 @@ public interface ITestFrameworkCapability : ICapability
}
```
-As you can see, the `ICapability` interface is a *marker* interface because it can represent *any capability*, and the actual implementation will be context dependent. You'll also observe the `ITestFrameworkCapability`, which inherits from `ICapability` to classify the capability. The capability system's generic nature allows for convenient grouping by context. The `ITestFrameworkCapability` groups all the capabilities implemented by the [testing framework](./unit-testing-platform-architecture-extensions.md#create-a-testing-framework). The `ICapabilities<TCapability>` interface reveals the *set* of all capabilities implemented by an extension. Similarly, for the base one, there's a context-specific testing framework called `ITestFrameworkCapabilities`. The `ITestFrameworkCapabilities` is provided to the platform during the [testing framework registration](./unit-testing-platform-architecture-extensions.md#register-a-testing-framework) process.
+As you can see, the `ICapability` interface is a *marker* interface because it can represent *any capability*, and the actual implementation will be context dependent. You'll also observe the `ITestFrameworkCapability`, which inherits from `ICapability` to classify the capability. The capability system's generic nature allows for convenient grouping by context. The `ITestFrameworkCapability` groups all the capabilities implemented by the [testing framework](./microsoft-testing-platform-architecture-extensions.md#create-a-testing-framework). The `ICapabilities<TCapability>` interface reveals the *set* of all capabilities implemented by an extension. Similarly, for the base one, there's a context-specific testing framework called `ITestFrameworkCapabilities`. The `ITestFrameworkCapabilities` is provided to the platform during the [testing framework registration](./microsoft-testing-platform-architecture-extensions.md#register-a-testing-framework) process.
To create a capability that addresses the aforementioned scenario, you define it as follows:
@@ -102,7 +102,7 @@ else
The preceding example illustrates how the capability infrastructure enables a powerful mechanism for communicating abilities between the components involved in a test session. While the sample demonstrates a capability specifically designed for the testing framework, any component can expose and implement extensions that inherit from `ICapability`.
-It's evident that not all details can be communicated through an interface. Considering the previous example, what should the extension expect if the `CanProvidePerTestCpuConsumption` is supported? What kind of custom information is expected to be transmitted via the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service) by the testing framework? The solution is **documentation of the capability**. It's the responsibility of the capability *owner* to design, ship, and document it as clearly as possible to assist implementors who want to effectively *collaborate* with the extension that requires the specific capability.
+It's evident that not all details can be communicated through an interface. Considering the previous example, what should the extension expect if the `CanProvidePerTestCpuConsumption` is supported? What kind of custom information is expected to be transmitted via the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) by the testing framework? The solution is **documentation of the capability**. It's the responsibility of the capability *owner* to design, ship, and document it as clearly as possible to assist implementors who want to effectively *collaborate* with the extension that requires the specific capability.
For instance, the TRX report extension enables the testing framework to implement the necessary capability to accurately generate a TRX report. The extension to register is included in the <https://www.nuget.org/packages/Microsoft.Testing.Extensions.TrxReport> NuGet package, but the capability to implement is found in the *contract only*<https://www.nuget.org/packages/Microsoft.Testing.Extensions.TrxReport.Abstractions> NuGet package.
@@ -115,7 +115,7 @@ In conclusion, let's summarize the primary aspects of the capability system:
## Framework capabilities
-The platform exposes a specialized interface named `ITestFrameworkCapability` that is the base of all capabilities exposed for test frameworks. These capabilities are provided when [registering the test framework to the platform](./unit-testing-platform-architecture-extensions.md#register-a-testing-framework).
+The platform exposes a specialized interface named `ITestFrameworkCapability` that is the base of all capabilities exposed for test frameworks. These capabilities are provided when [registering the test framework to the platform](./microsoft-testing-platform-architecture-extensions.md#register-a-testing-framework).
### `IBannerMessageOwnerCapability`
@@ -123,4 +123,4 @@ An optional [test framework capability](#framework-capabilities) that allows the
This capability implementation allows you to abstract away the various conditions that the test framework may need to consider when deciding whether or not the banner message should be displayed.
-The platform exposes the [`IPlatformInformation` service](./unit-testing-platform-architecture-services.md#the-iplatforminformation-service) to provide some information about the platform that could be useful when building your custom banner message.
+The platform exposes the [`IPlatformInformation` service](./microsoft-testing-platform-architecture-services.md#the-iplatforminformation-service) to provide some information about the platform that could be useful when building your custom banner message.
diff --git a/docs/core/testing/unit-testing-platform-architecture-extensions.md b/docs/core/testing/microsoft-testing-platform-architecture-extensions.md
similarity index 87%
rename from docs/core/testing/unit-testing-platform-architecture-extensions.md
rename to docs/core/testing/microsoft-testing-platform-architecture-extensions.md
index 492bea52f495a..bd21e71864169 100644
--- a/docs/core/testing/unit-testing-platform-architecture-extensions.md
+++ b/docs/core/testing/microsoft-testing-platform-architecture-extensions.md
@@ -10,7 +10,7 @@ ms.date: 07/11/2024
The testing platform consists of a [testing framework](#test-framework-extension) and any number of [extensions](#other-extensibility-points) that can operate *in-process* or *out-of-process*.
-As outlined in the [architecture](./unit-testing-platform-architecture.md) section, the testing platform is designed to accommodate a variety of scenarios and extensibility points. The primary and essential extension is undoubtedly the [testing framework](#test-framework-extension) that your tests will utilize. Failing to register this results in startup error. **The [testing framework](#test-framework-extension) is the sole mandatory extension required to execute a testing session.**
+As outlined in the [architecture](./microsoft-testing-platform-architecture.md) section, the testing platform is designed to accommodate a variety of scenarios and extensibility points. The primary and essential extension is undoubtedly the [testing framework](#test-framework-extension) that your tests will utilize. Failing to register this results in startup error. **The [testing framework](#test-framework-extension) is the sole mandatory extension required to execute a testing session.**
To support scenarios such as generating test reports, code coverage, retrying failed tests, and other potential features, you need to provide a mechanism that allows other extensions to work in conjunction with the [testing framework](#test-framework-extension) to deliver these features not inherently provided by the [testing framework](#test-framework-extension) itself.
@@ -18,7 +18,7 @@ In essence, the [testing framework](#test-framework-extension) is the primary ex
The extensibility point enables the utilization of information provided by the [testing framework](#test-framework-extension) to generate new artifacts or to enhance existing ones with additional features. A commonly used extension is the TRX report generator, which subscribes to the [TestNodeUpdateMessage](#the-testnodeupdatemessage-data) and generates an XML report file from it.
-As discussed in the [architecture](./unit-testing-platform-architecture.md), there are certain extension points that *cannot* operate within the same process as the [testing framework](#test-framework-extension). The reasons typically include:
+As discussed in the [architecture](./microsoft-testing-platform-architecture.md), there are certain extension points that *cannot* operate within the same process as the [testing framework](#test-framework-extension). The reasons typically include:
* The need to modify the *environment variables* of the *test host*. Acting within the test host process itself is *too late*.
* The requirement to *monitor* the process from the outside because the *test host*, where tests and user code run, might have some *user code bugs* that render the process itself *unstable*, leading to potential *hangs* or *crashes*. In such cases, the extension would crash or hang along with the *test host* process.
@@ -72,7 +72,7 @@ public interface IExtension
* `Description`: The description of the extension, that appears when you request information using the `--info` command line option.
-* `IsEnabledAsync()`: This method is invoked by the testing platform when the extension is being instantiated. If the method returns `false`, the extension will be excluded. This method typically makes decisions based on the [configuration file](./unit-testing-platform-architecture-services.md#the-iconfiguration-service) or some [custom command line options](./unit-testing-platform-architecture-services.md#the-icommandlineoptions-service). Users often specify `--customExtensionOption` in the command line to opt into the extension itself.
+* `IsEnabledAsync()`: This method is invoked by the testing platform when the extension is being instantiated. If the method returns `false`, the extension will be excluded. This method typically makes decisions based on the [configuration file](./microsoft-testing-platform-architecture-services.md#the-iconfiguration-service) or some [custom command line options](./microsoft-testing-platform-architecture-services.md#the-icommandlineoptions-service). Users often specify `--customExtensionOption` in the command line to opt into the extension itself.
## Test framework extension
@@ -80,7 +80,7 @@ The test framework is the primary extension that provides the testing platform w
### Register a testing framework
-This section explains how to register the test framework with the testing platform. You register only one testing framework per test application builder using the `TestApplication.RegisterTestFramework` API as shown in [the testing platform architecture](./unit-testing-platform-architecture.md) documentation.
+This section explains how to register the test framework with the testing platform. You register only one testing framework per test application builder using the `TestApplication.RegisterTestFramework` API as shown in [the testing platform architecture](./microsoft-testing-platform-architecture.md) documentation.
The registration API is defined as follows:
@@ -92,13 +92,13 @@ ITestApplicationBuilder RegisterTestFramework(
The `RegisterTestFramework` API expects two factories:
-1. `Func<IServiceProvider, ITestFrameworkCapabilities>`: This is a delegate that accepts an object implementing the [`IServiceProvider`](./unit-testing-platform-architecture-services.md) interface and returns an object implementing the [`ITestFrameworkCapabilities`](./unit-testing-platform-architecture-capabilities.md) interface. The [`IServiceProvider`](./unit-testing-platform-architecture-services.md#the-imessagebus-service) provides access to platform services such as configurations, loggers, and command line arguments.
+1. `Func<IServiceProvider, ITestFrameworkCapabilities>`: This is a delegate that accepts an object implementing the [`IServiceProvider`](./microsoft-testing-platform-architecture-services.md) interface and returns an object implementing the [`ITestFrameworkCapabilities`](./microsoft-testing-platform-architecture-capabilities.md) interface. The [`IServiceProvider`](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) provides access to platform services such as configurations, loggers, and command line arguments.
- The [`ITestFrameworkCapabilities`](./unit-testing-platform-architecture-capabilities.md) interface is used to announce the capabilities supported by the testing framework to the platform and extensions. It allows the platform and extensions to interact correctly by implementing and supporting specific behaviors. For a better understanding of the [concept of capabilities](./unit-testing-platform-architecture-capabilities.md), refer to the respective section.
+ The [`ITestFrameworkCapabilities`](./microsoft-testing-platform-architecture-capabilities.md) interface is used to announce the capabilities supported by the testing framework to the platform and extensions. It allows the platform and extensions to interact correctly by implementing and supporting specific behaviors. For a better understanding of the [concept of capabilities](./microsoft-testing-platform-architecture-capabilities.md), refer to the respective section.
-1. `Func<ITestFrameworkCapabilities, IServiceProvider, ITestFramework>`: This is a delegate that takes in an [ITestFrameworkCapabilities](./unit-testing-platform-architecture-capabilities.md) object, which is the instance returned by the `Func<IServiceProvider, ITestFrameworkCapabilities>`, and an [IServiceProvider](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to provide access to platform services once more. The expected return object is one that implements the [ITestFramework](#test-framework-extension) interface. The `ITestFramework` serves as the execution engine that discovers and runs tests, and then communicates the results back to the testing platform.
+1. `Func<ITestFrameworkCapabilities, IServiceProvider, ITestFramework>`: This is a delegate that takes in an [ITestFrameworkCapabilities](./microsoft-testing-platform-architecture-capabilities.md) object, which is the instance returned by the `Func<IServiceProvider, ITestFrameworkCapabilities>`, and an [IServiceProvider](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to provide access to platform services once more. The expected return object is one that implements the [ITestFramework](#test-framework-extension) interface. The `ITestFramework` serves as the execution engine that discovers and runs tests, and then communicates the results back to the testing platform.
-The need for the platform to separate the creation of the [`ITestFrameworkCapabilities`](./unit-testing-platform-architecture-capabilities.md) and the creation of the [ITestFramework](#test-framework-extension) is an optimization to avoid creating the test framework if the supported capabilities are not sufficient to execute the current testing session.
+The need for the platform to separate the creation of the [`ITestFrameworkCapabilities`](./microsoft-testing-platform-architecture-capabilities.md) and the creation of the [ITestFramework](#test-framework-extension) is an optimization to avoid creating the test framework if the supported capabilities are not sufficient to execute the current testing session.
Consider the following user code example, which demonstrates a test framework registration that returns an empty capability set:
@@ -141,7 +141,7 @@ return await testApplication.RunAsync();
```
> [!NOTE]
-> Returning empty [ITestFrameworkCapabilities](./unit-testing-platform-architecture-capabilities.md) shouldn't prevent the execution of the test session. All test frameworks should be capable of discovering and running tests. The impact should be limited to extensions that may opt-out if the test framework lacks a certain feature.
+> Returning empty [ITestFrameworkCapabilities](./microsoft-testing-platform-architecture-capabilities.md) shouldn't prevent the execution of the test session. All test frameworks should be capable of discovering and running tests. The impact should be limited to extensions that may opt-out if the test framework lacks a certain feature.
### Create a testing framework
@@ -228,7 +228,7 @@ The testing platform monitors all dispatched requests. Once all requests have be
It's evident that the requests and their completions can overlap, enabling concurrent and asynchronous execution of requests.
> [!NOTE]
-> Currently, the testing platform does not send overlapping requests and waits for the completion of a request >> before sending the next one. However, this behavior may change in the future. The support for concurrent requests will be determined through the [capabilities](./unit-testing-platform-architecture-capabilities.md) system.
+> Currently, the testing platform does not send overlapping requests and waits for the completion of a request >> before sending the next one. However, this behavior may change in the future. The support for concurrent requests will be determined through the [capabilities](./microsoft-testing-platform-architecture-capabilities.md) system.
The `IRequest` implementation specifies the precise request that needs to be fulfilled. The test framework identifies the type of request and handles it accordingly. If the request type is unrecognized, an exception should be raised.
@@ -236,22 +236,22 @@ You can find details about the available requests in the [IRequest](#handling-re
`IMessageBus`: This service, linked with the request, allows the test framework to *asynchronously* to publish information about the ongoing request to the testing platform.
The message bus serves as the central hub for the platform, facilitating asynchronous communication among all platform components and extensions.
-For a comprehensive list of information that can be published to the testing platform, refer to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service) section.
+For a comprehensive list of information that can be published to the testing platform, refer to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) section.
`CancellationToken`: This token is utilized to interrupt the processing of a particular request.
-`Complete()`: As depicted in the previous sequence, the `Complete` method notifies the platform that the request has been successfully processed and all relevant information has been transmitted to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service).
+`Complete()`: As depicted in the previous sequence, the `Complete` method notifies the platform that the request has been successfully processed and all relevant information has been transmitted to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service).
> [!WARNING]
> Neglecting to invoke `Complete()` on the request will result in the test application becoming unresponsive.
-To customize your test framework according to your requirements or those of your users, you can use a personalized section inside the [configuration](./unit-testing-platform-architecture-services.md#the-iconfiguration-service) file or with custom [command line options](#the-icommandlineoptionsprovider-extensions).
+To customize your test framework according to your requirements or those of your users, you can use a personalized section inside the [configuration](./microsoft-testing-platform-architecture-services.md#the-iconfiguration-service) file or with custom [command line options](#the-icommandlineoptionsprovider-extensions).
### Handling requests
The subsequent section provides a detailed description of the various requests that a test framework may receive and process.
-Before proceeding to the next section, it's crucial to thoroughly comprehend the concept of the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service), which is the essential service for conveying test execution information to the testing platform.
+Before proceeding to the next section, it's crucial to thoroughly comprehend the concept of the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service), which is the essential service for conveying test execution information to the testing platform.
#### TestSessionContext
@@ -291,7 +291,7 @@ public class DiscoverTestExecutionRequest
}
```
-The `DiscoverTestExecutionRequest` instructs the test framework **to discover** the tests and communicate this information thought to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service).
+The `DiscoverTestExecutionRequest` instructs the test framework **to discover** the tests and communicate this information thought to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service).
As outlined in the previous section, the property for a discovered test is `DiscoveredTestNodeStateProperty`. Here is a generic code snippet for reference:
@@ -326,7 +326,7 @@ public class RunTestExecutionRequest
}
```
-The `RunTestExecutionRequest` instructs the test framework **to execute** the tests and communicate this information thought to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service).
+The `RunTestExecutionRequest` instructs the test framework **to execute** the tests and communicate this information thought to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service).
Here is a generic code snippet for reference:
@@ -396,7 +396,7 @@ await context.MessageBus.PublishAsync(
### The `TestNodeUpdateMessage` data
-As mentioned in the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service) section, before utilizing the message bus, you must specify the type of data you intend to supply. The testing platform has defined a well-known type, `TestNodeUpdateMessage`, to represent the concept of a *test update information*.
+As mentioned in the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) section, before utilizing the message bus, you must specify the type of data you intend to supply. The testing platform has defined a well-known type, `TestNodeUpdateMessage`, to represent the concept of a *test update information*.
This part of the document will explain how to utilize this payload data. Let's examine the surface:
@@ -777,7 +777,7 @@ The testing platform provides additional extensibility points that allow you to
> [!NOTE]
> When extending this API, the custom extension will exists both in and out of the test host process.
-As discussed in the [architecture](./unit-testing-platform-architecture.md) section, the initial step involves creating the `ITestApplicationBuilder` to register the testing framework and extensions with it.
+As discussed in the [architecture](./microsoft-testing-platform-architecture.md) section, the initial step involves creating the `ITestApplicationBuilder` to register the testing framework and extensions with it.
```csharp
var builder = await TestApplication.CreateBuilderAsync(args);
@@ -898,7 +898,7 @@ public Task<ValidationResult> ValidateCommandLineOptionsAsync(ICommandLineOption
}
```
-Please note that the `ValidateCommandLineOptionsAsync` method provides the [`ICommandLineOptions`](./unit-testing-platform-architecture-services.md#the-icommandlineoptions-service) service, which is used to fetch the argument information parsed by the platform itself.
+Please note that the `ValidateCommandLineOptionsAsync` method provides the [`ICommandLineOptions`](./microsoft-testing-platform-architecture-services.md#the-icommandlineoptions-service) service, which is used to fetch the argument information parsed by the platform itself.
### The `ITestSessionLifetimeHandler` extensions
@@ -915,7 +915,7 @@ builder.TestHost.AddTestSessionLifetimeHandle(
static serviceProvider => new CustomTestSessionLifeTimeHandler());
```
-The factory utilizes the [IServiceProvider](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
+The factory utilizes the [IServiceProvider](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
> [!IMPORTANT]
> The sequence of registration is significant, as the APIs are called in the order they were registered.
@@ -950,7 +950,7 @@ Consider the following details for this API:
`OnTestSessionStartingAsync`: This method is invoked prior to the commencement of the test session and receives the `SessionUid` object, which provides an opaque identifier for the current test session.
-`OnTestSessionFinishingAsync`: This method is invoked after the completion of the test session, ensuring that the [testing framework](#test-framework-extension) has finished executing all tests and has reported all relevant data to the platform. Typically, in this method, the extension employs the [`IMessageBus`](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to transmit custom assets or data to the shared platform bus. This method can also signal to any custom *out-of-process* extension that the test session has concluded.
+`OnTestSessionFinishingAsync`: This method is invoked after the completion of the test session, ensuring that the [testing framework](#test-framework-extension) has finished executing all tests and has reported all relevant data to the platform. Typically, in this method, the extension employs the [`IMessageBus`](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to transmit custom assets or data to the shared platform bus. This method can also signal to any custom *out-of-process* extension that the test session has concluded.
Finally, both APIs take a `CancellationToken` which the extension is expected to honor.
@@ -972,7 +972,7 @@ builder.TestHost.AddTestApplicationLifecycleCallbacks(
=> new CustomTestApplicationLifecycleCallbacks());
```
-The factory utilizes the [IServiceProvider](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
+The factory utilizes the [IServiceProvider](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
> [!IMPORTANT]
> The sequence of registration is significant, as the APIs are called in the order they were registered.
@@ -1000,13 +1000,13 @@ The `ITestApplicationLifecycleCallbacks` is a type of `ITestHostExtension`, whic
*For example, the built-in hang dump feature is composed of both *in-process* and *out-of-process* extensions, and this method is used to exchange information with the *out-of-process* component of the extension.*
-`AfterRunAsync`: This method is the final call before exiting the [`int ITestApplication.RunAsync()`](./unit-testing-platform-architecture.md) and it provides the [`exit code`](./unit-testing-platform-exit-codes.md). It should be used solely for cleanup tasks and to notify any corresponding *out-of-process* extension that the *test host* is about to terminate.
+`AfterRunAsync`: This method is the final call before exiting the [`int ITestApplication.RunAsync()`](./microsoft-testing-platform-architecture.md) and it provides the [`exit code`](./microsoft-testing-platform-exit-codes.md). It should be used solely for cleanup tasks and to notify any corresponding *out-of-process* extension that the *test host* is about to terminate.
Finally, both APIs take a `CancellationToken` which the extension is expected to honor.
### The `IDataConsumer` extensions
-The `IDataConsumer` is an *in-process* extension capable of subscribing to and receiving `IData` information that is pushed to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service) by the [testing framework](#test-framework-extension) and its extensions.
+The `IDataConsumer` is an *in-process* extension capable of subscribing to and receiving `IData` information that is pushed to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) by the [testing framework](#test-framework-extension) and its extensions.
*This extension point is crucial as it enables developers to gather and process all the information generated during a test session.*
@@ -1021,7 +1021,7 @@ builder.TestHost.AddDataConsumer(
static serviceProvider => new CustomDataConsumer());
```
-The factory utilizes the [IServiceProvider](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
+The factory utilizes the [IServiceProvider](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
> [!IMPORTANT]
> The sequence of registration is significant, as the APIs are called in the order they were registered.
@@ -1050,7 +1050,7 @@ The `IDataConsumer` is a type of `ITestHostExtension`, which serves as a base fo
`DataTypesConsumed`: This property returns a list of `Type` that this extension plans to consume. It corresponds to `IDataProducer.DataTypesProduced`. Notably, an `IDataConsumer` can subscribe to multiple types originating from different `IDataProducer` instances without any issues.
-`ConsumeAsync`: This method is triggered whenever data of a type to which the current consumer is subscribed is pushed onto the [`IMessageBus`](./unit-testing-platform-architecture-services.md#the-imessagebus-service). It receives the `IDataProducer` to provide details about the data payload's producer, as well as the `IData` payload itself. As you can see, `IData` is a generic placeholder interface that contains general informative data. The ability to push different types of `IData` implies that the consumer needs to *switch* on the type itself to cast it to the correct type and access the specific information.
+`ConsumeAsync`: This method is triggered whenever data of a type to which the current consumer is subscribed is pushed onto the [`IMessageBus`](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service). It receives the `IDataProducer` to provide details about the data payload's producer, as well as the `IData` payload itself. As you can see, `IData` is a generic placeholder interface that contains general informative data. The ability to push different types of `IData` implies that the consumer needs to *switch* on the type itself to cast it to the correct type and access the specific information.
A sample implementation of a consumer that wants to elaborate the [`TestNodeUpdateMessage`](#the-testnodeupdatemessage-data) produced by a [testing framework](#test-framework-extension) could be:
@@ -1100,18 +1100,18 @@ internal class CustomDataConsumer : IDataConsumer, IOutputDeviceDataProducer
Finally, the API takes a `CancellationToken` which the extension is expected to honor.
> [!IMPORTANT]
-> It's crucial to process the payload directly within the `ConsumeAsync` method. The [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service) can manage both synchronous and asynchronous processing, coordinating the execution with the [testing framework](#test-framework-extension). Although the consumption process is entirely asynchronous and doesn't block the [IMessageBus.Push](./unit-testing-platform-architecture-services.md#the-imessagebus-service) at the time of writing, this is an implementation detail that may change in the future due to future requirements. However, the platform ensures that this method is always called once, eliminating the need for complex synchronization, as well as managing the scalability of the consumers.
+> It's crucial to process the payload directly within the `ConsumeAsync` method. The [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) can manage both synchronous and asynchronous processing, coordinating the execution with the [testing framework](#test-framework-extension). Although the consumption process is entirely asynchronous and doesn't block the [IMessageBus.Push](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) at the time of writing, this is an implementation detail that may change in the future due to future requirements. However, the platform ensures that this method is always called once, eliminating the need for complex synchronization, as well as managing the scalability of the consumers.
<!-- avoid "No space in block quote" block quotes follow each other -->
> [!WARNING]
-> When using `IDataConsumer` in conjunction with [ITestHostProcessLifetimeHandler](#the-itestsessionlifetimehandler-extensions) within a [composite extension point](#the-compositeextensionfactoryt), **it's crucial to disregard any data received post the execution of [ITestSessionLifetimeHandler.OnTestSessionFinishingAsync](#the-itestsessionlifetimehandler-extensions)**. The `OnTestSessionFinishingAsync` is the final opportunity to process accumulated data and transmit new information to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service), hence, any data consumed beyond this point will not be *utilizable* by the extension.
+> When using `IDataConsumer` in conjunction with [ITestHostProcessLifetimeHandler](#the-itestsessionlifetimehandler-extensions) within a [composite extension point](#the-compositeextensionfactoryt), **it's crucial to disregard any data received post the execution of [ITestSessionLifetimeHandler.OnTestSessionFinishingAsync](#the-itestsessionlifetimehandler-extensions)**. The `OnTestSessionFinishingAsync` is the final opportunity to process accumulated data and transmit new information to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service), hence, any data consumed beyond this point will not be *utilizable* by the extension.
If your extension requires intensive initialization and you need to use the async/await pattern, you can refer to the [`Async extension initialization and cleanup`](#asynchronous-initialization-and-cleanup-of-extensions). If you need to *share state* between extension points, you can refer to the [`CompositeExtensionFactory<T>`](#the-compositeextensionfactoryt) section.
### The `ITestHostEnvironmentVariableProvider` extensions
-The `ITestHostEnvironmentVariableProvider` is an *out-of-process* extension that enables you to establish custom environment variables for the test host. Utilizing this extension point ensures that the testing platform will initiate a new host with the appropriate environment variables, as detailed in the [architecture](./unit-testing-platform-architecture.md) section.
+The `ITestHostEnvironmentVariableProvider` is an *out-of-process* extension that enables you to establish custom environment variables for the test host. Utilizing this extension point ensures that the testing platform will initiate a new host with the appropriate environment variables, as detailed in the [architecture](./microsoft-testing-platform-architecture.md) section.
To register a custom `ITestHostEnvironmentVariableProvider`, utilize the following API:
@@ -1124,7 +1124,7 @@ builder.TestHostControllers.AddEnvironmentVariableProvider(
static serviceProvider => new CustomEnvironmentVariableForTestHost());
```
-The factory utilizes the [IServiceProvider](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
+The factory utilizes the [IServiceProvider](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
> [!IMPORTANT]
> The sequence of registration is significant, as the APIs are called in the order they were registered.
@@ -1194,7 +1194,7 @@ If your extension requires intensive initialization and you need to use the asyn
### The `ITestHostProcessLifetimeHandler` extensions
-The `ITestHostProcessLifetimeHandler` is an *out-of-process* extension that allows you to observe the test host process from an external standpoint. This ensures that your extension remains unaffected by potential crashes or hangs that could be induced by the code under test. Utilizing this extension point will prompt the testing platform to initiate a new host, as detailed in the [architecture](./unit-testing-platform-architecture.md) section.
+The `ITestHostProcessLifetimeHandler` is an *out-of-process* extension that allows you to observe the test host process from an external standpoint. This ensures that your extension remains unaffected by potential crashes or hangs that could be induced by the code under test. Utilizing this extension point will prompt the testing platform to initiate a new host, as detailed in the [architecture](./microsoft-testing-platform-architecture.md) section.
To register a custom `ITestHostProcessLifetimeHandler`, utilize the following API:
@@ -1207,7 +1207,7 @@ builder.TestHostControllers.AddProcessLifetimeHandler(
static serviceProvider => new CustomMonitorTestHost());
```
-The factory utilizes the [IServiceProvider](./unit-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
+The factory utilizes the [IServiceProvider](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) to gain access to the suite of services offered by the testing platform.
> [!IMPORTANT]
> The sequence of registration is significant, as the APIs are called in the order they were registered.
@@ -1266,7 +1266,7 @@ The testing platform consists of a [testing framework](#test-framework-extension
1. [ITestApplicationLifecycleCallbacks.BeforeRunAsync](#the-itestsessionlifetimehandler-extensions): In-process
1. [ITestSessionLifetimeHandler.OnTestSessionStartingAsync](#the-itestsessionlifetimehandler-extensions): In-process
1. [ITestFramework.CreateTestSessionAsync](#test-framework-extension): In-process
-1. [ITestFramework.ExecuteRequestAsync](#test-framework-extension): In-process, this method can be called one or more times. At this point, the testing framework will transmit information to the [IMessageBus](./unit-testing-platform-architecture-services.md#the-imessagebus-service) that can be utilized by the [IDataConsumer](#the-idataconsumer-extensions).
+1. [ITestFramework.ExecuteRequestAsync](#test-framework-extension): In-process, this method can be called one or more times. At this point, the testing framework will transmit information to the [IMessageBus](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) that can be utilized by the [IDataConsumer](#the-idataconsumer-extensions).
1. [ITestFramework.CloseTestSessionAsync](#test-framework-extension): In-process
1. [ITestSessionLifetimeHandler.OnTestSessionFinishingAsync](#the-itestsessionlifetimehandler-extensions): In-process
1. [ITestApplicationLifecycleCallbacks.AfterRunAsync](#the-itestsessionlifetimehandler-extensions): In-process
@@ -1315,7 +1315,7 @@ However, if you need to *share state* between two extensions, the fact that you
Hence, the testing platform provides a sophisticated method to implement multiple extension points using the same type, making data sharing a straightforward task. All you need to do is utilize the `CompositeExtensionFactory<T>`, which can then be registered using the same API as you would for a single interface implementation.
-For instance, consider a type that implements both `ITestSessionLifetimeHandler` and `IDataConsumer`. This is a common scenario because you often want to gather information from the [testing framework](#test-framework-extension) and then, when the testing session concludes, you'll dispatch your artifact using the [`IMessageBus`](./unit-testing-platform-architecture-services.md#the-imessagebus-service) within the `ITestSessionLifetimeHandler.OnTestSessionFinishingAsync`.
+For instance, consider a type that implements both `ITestSessionLifetimeHandler` and `IDataConsumer`. This is a common scenario because you often want to gather information from the [testing framework](#test-framework-extension) and then, when the testing session concludes, you'll dispatch your artifact using the [`IMessageBus`](./microsoft-testing-platform-architecture-services.md#the-imessagebus-service) within the `ITestSessionLifetimeHandler.OnTestSessionFinishingAsync`.
What you should do is to normally implement the interfaces:
@@ -1339,7 +1339,7 @@ builder.TestHost.AddTestSessionLifetimeHandle(factory);
builder.TestHost.AddDataConsumer(factory);
```
-The factory constructor employs the [IServiceProvider](./unit-testing-platform-architecture-services.md) to access the services provided by the testing platform.
+The factory constructor employs the [IServiceProvider](./microsoft-testing-platform-architecture-services.md) to access the services provided by the testing platform.
The testing platform will be responsible for managing the lifecycle of the composite extension.
diff --git a/docs/core/testing/unit-testing-platform-architecture-services.md b/docs/core/testing/microsoft-testing-platform-architecture-services.md
similarity index 91%
rename from docs/core/testing/unit-testing-platform-architecture-services.md
rename to docs/core/testing/microsoft-testing-platform-architecture-services.md
index 09aebe7b027c4..9de66c0481eb5 100644
--- a/docs/core/testing/unit-testing-platform-architecture-services.md
+++ b/docs/core/testing/microsoft-testing-platform-architecture-services.md
@@ -52,7 +52,7 @@ public static class ServiceProviderExtensions
}
```
-Most of the registration factories exposed by extension points provide access to the `IServiceProvider`: For example, when [registering the testing framework](./unit-testing-platform-architecture-extensions.md#register-a-testing-framework), the `IServiceProvider` is passed as a parameter to the factory method.
+Most of the registration factories exposed by extension points provide access to the `IServiceProvider`: For example, when [registering the testing framework](./microsoft-testing-platform-architecture-extensions.md#register-a-testing-framework), the `IServiceProvider` is passed as a parameter to the factory method.
```csharp
ITestApplicationBuilder RegisterTestFramework(
@@ -166,7 +166,7 @@ public interface ICommandLineOptions
}
```
-The `ICommandLineOptions` can be obtained through certain APIs, such as the [ICommandLineOptionsProvider](./unit-testing-platform-architecture-extensions.md#the-icommandlineoptionsprovider-extensions), or you can retrieve an instance of it from the [IServiceProvider](#microsofttestingplatform-services) via the extension method `serviceProvider.GetCommandLineOptions()`.
+The `ICommandLineOptions` can be obtained through certain APIs, such as the [ICommandLineOptionsProvider](./microsoft-testing-platform-architecture-extensions.md#the-icommandlineoptionsprovider-extensions), or you can retrieve an instance of it from the [IServiceProvider](#microsofttestingplatform-services) via the extension method `serviceProvider.GetCommandLineOptions()`.
`ICommandLineOptions.IsOptionSet(string optionName)`: This method allows you to verify whether a specific option has been specified. When specifying the `optionName`, omit the `--` prefix. For example, if the user inputs `--myOption`, you should simply pass `myOption`.
@@ -319,16 +319,16 @@ public interface IData
Consider the following details about the parameters:
-* `IDataProducer`: The `IDataProducer` communicates to the message bus the `Type` of information it can supply and establishes ownership through inheritance from the base interface [IExtension](./unit-testing-platform-architecture-extensions.md#the-iextension-interface). This implies that you can't indiscriminately push data to the message bus; you must declare the data type produced in advance. If you push unexpected data, an exception will be triggered.
+* `IDataProducer`: The `IDataProducer` communicates to the message bus the `Type` of information it can supply and establishes ownership through inheritance from the base interface [IExtension](./microsoft-testing-platform-architecture-extensions.md#the-iextension-interface). This implies that you can't indiscriminately push data to the message bus; you must declare the data type produced in advance. If you push unexpected data, an exception will be triggered.
* `IData`: This interface serves as a placeholder where you only need to provide descriptive details such as the name and a description. The interface doesn't reveal much about the data's nature, which is intentional. It implies that the test framework and extensions can push any type of data to the bus, and this data can be consumed by any registered extension or the test framework itself.
This approach facilitates the evolution of the information exchange process, preventing breaking changes when an extension is unfamiliar with new data. **It allows different versions of extensions and the test framework to operate in harmony, based on their mutual understanding**.
-The opposite end of the bus is referred to as a [consumer](./unit-testing-platform-architecture-extensions.md#the-idataconsumer-extensions), which is subscribed to a specific type of data and can thus consume it.
+The opposite end of the bus is referred to as a [consumer](./microsoft-testing-platform-architecture-extensions.md#the-idataconsumer-extensions), which is subscribed to a specific type of data and can thus consume it.
> [!IMPORTANT]
-> Always use *await* the call to `PublishAsync`. If you don't, the `IData` might not be processed correctly by the testing platform and extensions, which could lead to subtle bugs. It's only after you've returned from the *await* that you can be assured that the `IData` has been queued for processing on the message bus. Regardless of the extension point you're working on, ensure that you've awaited all `PublishAsync` calls before exiting the extension. For example, if you're implementing the [`testing framework`](./unit-testing-platform-architecture-extensions.md#create-a-testing-framework), you should not call `Complete` on the [requests](./unit-testing-platform-architecture-extensions.md#handling-requests) until you've awaited all `PublishAsync` calls for that specific request.
+> Always use *await* the call to `PublishAsync`. If you don't, the `IData` might not be processed correctly by the testing platform and extensions, which could lead to subtle bugs. It's only after you've returned from the *await* that you can be assured that the `IData` has been queued for processing on the message bus. Regardless of the extension point you're working on, ensure that you've awaited all `PublishAsync` calls before exiting the extension. For example, if you're implementing the [`testing framework`](./microsoft-testing-platform-architecture-extensions.md#create-a-testing-framework), you should not call `Complete` on the [requests](./microsoft-testing-platform-architecture-extensions.md#handling-requests) until you've awaited all `PublishAsync` calls for that specific request.
## The `IOutputDevice` service
@@ -360,7 +360,7 @@ public interface IOutputDeviceData
}
```
-The `IOutputDeviceDataProducer` extends the [`IExtension`](./unit-testing-platform-architecture-extensions.md#the-iextension-interface) and provides information about the sender to the *output device*.
+The `IOutputDeviceDataProducer` extends the [`IExtension`](./microsoft-testing-platform-architecture-extensions.md#the-iextension-interface) and provides information about the sender to the *output device*.
The `IOutputDeviceData` serves as a placeholder interface. The concept behind `IOutputDevice` is to accommodate more intricate information than just colored text. For instance, it could be a complex object that can be graphically represented.
diff --git a/docs/core/testing/unit-testing-platform-architecture.md b/docs/core/testing/microsoft-testing-platform-architecture.md
similarity index 96%
rename from docs/core/testing/unit-testing-platform-architecture.md
rename to docs/core/testing/microsoft-testing-platform-architecture.md
index d497607ee958b..1385d0ccf05ff 100644
--- a/docs/core/testing/unit-testing-platform-architecture.md
+++ b/docs/core/testing/microsoft-testing-platform-architecture.md
@@ -81,7 +81,7 @@ Passed! - Failed: 0, Passed: 1, Skipped: 0, Total: 1, Duration: 5ms - Contoso.Un
```
> [!NOTE]
-> The known exit codes returned by the `ITestApplication.RunAsync()` call are detailed in [platform exit codes](./unit-testing-platform-exit-codes.md).
+> The known exit codes returned by the `ITestApplication.RunAsync()` call are detailed in [platform exit codes](./microsoft-testing-platform-exit-codes.md).
## Step 2: Extending the platform
@@ -158,10 +158,10 @@ The above section provides a brief introduction to the architecture of the testi
## Step 3: Comprehensive Overview of Extension points
-Let's start by getting familiar with the concept of [capabilities](./unit-testing-platform-architecture-capabilities.md) before diving into the various [extensions points](./unit-testing-platform-architecture-extensions.md).
+Let's start by getting familiar with the concept of [capabilities](./microsoft-testing-platform-architecture-capabilities.md) before diving into the various [extensions points](./microsoft-testing-platform-architecture-extensions.md).
## Step 4: Available services
The testing platform offers valuable services to both the testing framework and extension points. These services cater to common needs such as accessing the configuration, parsing and retrieving command-line arguments, obtaining the logging factory, and accessing the logging system, among others. `IServiceProvider` implements the _service locator pattern_ for the testing platform.
-All the services, helpers, and technical information about how to access and use these services is listed in [Microsoft.Testing.Platform Services documentation](./unit-testing-platform-architecture-services.md).
+All the services, helpers, and technical information about how to access and use these services is listed in [Microsoft.Testing.Platform Services documentation](./microsoft-testing-platform-architecture-services.md).
diff --git a/docs/core/testing/unit-testing-platform-config.md b/docs/core/testing/microsoft-testing-platform-config.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-config.md
rename to docs/core/testing/microsoft-testing-platform-config.md
diff --git a/docs/core/testing/unit-testing-platform-diagnostics.md b/docs/core/testing/microsoft-testing-platform-diagnostics.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-diagnostics.md
rename to docs/core/testing/microsoft-testing-platform-diagnostics.md
diff --git a/docs/core/testing/unit-testing-platform-exit-codes.md b/docs/core/testing/microsoft-testing-platform-exit-codes.md
similarity index 94%
rename from docs/core/testing/unit-testing-platform-exit-codes.md
rename to docs/core/testing/microsoft-testing-platform-exit-codes.md
index f1ad13068992a..9fc5046812a8a 100644
--- a/docs/core/testing/unit-testing-platform-exit-codes.md
+++ b/docs/core/testing/microsoft-testing-platform-exit-codes.md
@@ -26,9 +26,9 @@ ms.topic: reference
| `10` | The exit code `10` indicates that the test adapter, Testing.Platform Test Framework, MSTest, NUnit, or xUnit, failed to run tests for an infrastructure reason unrelated to the test's self. An example is failing to create a fixture needed by tests. |
| `11` | The exit code `11` indicates that the test process will exit if dependent process exits. |
| `12` | The exit code `12` indicates that the test session was unable to run because the client does not support any of the supported protocol versions. |
-| `13` | The exit code `13` indicates that the test session was stopped due to reaching the specified number of maximum failed tests using `--maximum-failed-tests` command-line option. For more information, see [the Options section in Microsoft.Testing.Platform overview](unit-testing-platform-intro.md#options) |
+| `13` | The exit code `13` indicates that the test session was stopped due to reaching the specified number of maximum failed tests using `--maximum-failed-tests` command-line option. For more information, see [the Options section in Microsoft.Testing.Platform overview](microsoft-testing-platform-intro.md#options) |
-To enable verbose logging and troubleshoot issues, see [Microsoft.Testing.Platform Diagnostics extensions](unit-testing-platform-extensions-diagnostics.md#built-in-options).
+To enable verbose logging and troubleshoot issues, see [Microsoft.Testing.Platform Diagnostics extensions](microsoft-testing-platform-extensions-diagnostics.md#built-in-options).
## Ignore specific exit codes
diff --git a/docs/core/testing/unit-testing-platform-extensions-code-coverage.md b/docs/core/testing/microsoft-testing-platform-extensions-code-coverage.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-extensions-code-coverage.md
rename to docs/core/testing/microsoft-testing-platform-extensions-code-coverage.md
diff --git a/docs/core/testing/unit-testing-platform-extensions-diagnostics.md b/docs/core/testing/microsoft-testing-platform-extensions-diagnostics.md
similarity index 96%
rename from docs/core/testing/unit-testing-platform-extensions-diagnostics.md
rename to docs/core/testing/microsoft-testing-platform-extensions-diagnostics.md
index bfb34d8f067b8..e697cba7e9453 100644
--- a/docs/core/testing/unit-testing-platform-extensions-diagnostics.md
+++ b/docs/core/testing/microsoft-testing-platform-extensions-diagnostics.md
@@ -12,7 +12,7 @@ This article list and explains all `Microsoft Testing Platform` extensions relat
## Built-in options
-The following [platform options](./unit-testing-platform-intro.md#options) provide useful information for troubleshooting your test apps:
+The following [platform options](./microsoft-testing-platform-intro.md#options) provide useful information for troubleshooting your test apps:
- `--info`
- `--diagnostic`
diff --git a/docs/core/testing/unit-testing-platform-extensions-fakes.md b/docs/core/testing/microsoft-testing-platform-extensions-fakes.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-extensions-fakes.md
rename to docs/core/testing/microsoft-testing-platform-extensions-fakes.md
diff --git a/docs/core/testing/unit-testing-platform-extensions-hosting.md b/docs/core/testing/microsoft-testing-platform-extensions-hosting.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-extensions-hosting.md
rename to docs/core/testing/microsoft-testing-platform-extensions-hosting.md
diff --git a/docs/core/testing/unit-testing-platform-extensions-output.md b/docs/core/testing/microsoft-testing-platform-extensions-output.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-extensions-output.md
rename to docs/core/testing/microsoft-testing-platform-extensions-output.md
diff --git a/docs/core/testing/unit-testing-platform-extensions-policy.md b/docs/core/testing/microsoft-testing-platform-extensions-policy.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-extensions-policy.md
rename to docs/core/testing/microsoft-testing-platform-extensions-policy.md
diff --git a/docs/core/testing/unit-testing-platform-extensions-test-reports.md b/docs/core/testing/microsoft-testing-platform-extensions-test-reports.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-extensions-test-reports.md
rename to docs/core/testing/microsoft-testing-platform-extensions-test-reports.md
diff --git a/docs/core/testing/unit-testing-platform-extensions-vstest-bridge.md b/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md
similarity index 95%
rename from docs/core/testing/unit-testing-platform-extensions-vstest-bridge.md
rename to docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md
index 741973db57860..0defcca36927b 100644
--- a/docs/core/testing/unit-testing-platform-extensions-vstest-bridge.md
+++ b/docs/core/testing/microsoft-testing-platform-extensions-vstest-bridge.md
@@ -41,7 +41,7 @@ The following **RunConfiguration** elements are not supported by `Microsoft.Test
`Microsoft.Testing.Platform` is not using data collectors. Instead it has the concept of in-process and out-of-process extensions. Each extension is configured by its respective configuration file or through the command line.
-Most importantly [hang](unit-testing-platform-extensions-diagnostics.md#hang-dump) and [crash](unit-testing-platform-extensions-diagnostics.md#crash-dump) extension, and [code coverage](unit-testing-platform-extensions-code-coverage.md) extension.
+Most importantly [hang](microsoft-testing-platform-extensions-diagnostics.md#hang-dump) and [crash](microsoft-testing-platform-extensions-diagnostics.md#crash-dump) extension, and [code coverage](microsoft-testing-platform-extensions-code-coverage.md) extension.
### LoggerRunSettings element
diff --git a/docs/core/testing/unit-testing-platform-extensions.md b/docs/core/testing/microsoft-testing-platform-extensions.md
similarity index 74%
rename from docs/core/testing/unit-testing-platform-extensions.md
rename to docs/core/testing/microsoft-testing-platform-extensions.md
index 01dea3ee9bf41..62a9abec9b6d4 100644
--- a/docs/core/testing/unit-testing-platform-extensions.md
+++ b/docs/core/testing/microsoft-testing-platform-extensions.md
@@ -14,30 +14,30 @@ Each and every extension is shipped with its own licensing model (some less perm
## Extensions
-**[Code Coverage](./unit-testing-platform-extensions-code-coverage.md)**
+**[Code Coverage](./microsoft-testing-platform-extensions-code-coverage.md)**
Extensions designed to provide code coverage support.
-**[Diagnostics](./unit-testing-platform-extensions-diagnostics.md)**
+**[Diagnostics](./microsoft-testing-platform-extensions-diagnostics.md)**
Extensions offering diagnostics and troubleshooting functionalities.
-**[Hosting](./unit-testing-platform-extensions-hosting.md)**
+**[Hosting](./microsoft-testing-platform-extensions-hosting.md)**
Extensions affecting how the test execution is hosted.
-**[Policy](./unit-testing-platform-extensions-policy.md)**
+**[Policy](./microsoft-testing-platform-extensions-policy.md)**
Extensions allowing to define policies around the test execution.
-**[Test Reports](./unit-testing-platform-extensions-test-reports.md)**
+**[Test Reports](./microsoft-testing-platform-extensions-test-reports.md)**
Extensions allowing to produce test report files that contains information about the execution and outcome of the tests.
-**[VSTest Bridge](./unit-testing-platform-extensions-vstest-bridge.md)**
+**[VSTest Bridge](./microsoft-testing-platform-extensions-vstest-bridge.md)**
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`, usual `dotnet test`, `VSTest task` on AzDo, Test Explorers of Visual Studio and Visual Studio Code...).
-**[Microsoft Fakes](./unit-testing-platform-extensions-fakes.md)**
+**[Microsoft Fakes](./microsoft-testing-platform-extensions-fakes.md)**
This extension provides support to execute a test project that makes use of `Microsoft Fakes`.
diff --git a/docs/core/testing/unit-testing-platform-faq.md b/docs/core/testing/microsoft-testing-platform-faq.md
similarity index 97%
rename from docs/core/testing/unit-testing-platform-faq.md
rename to docs/core/testing/microsoft-testing-platform-faq.md
index 1f9def7cc38fd..fbc863b9c0c38 100644
--- a/docs/core/testing/unit-testing-platform-faq.md
+++ b/docs/core/testing/microsoft-testing-platform-faq.md
@@ -28,5 +28,5 @@ Manually defining an entry point (`Main`) in a test project or referencing a tes
This error can occur if not all of the Fakes assemblies are present in the bin folder.
-- Ensure that the project either uses the [MSTest.SDK](./unit-testing-mstest-sdk.md) or references [Microsoft.Testing.Extensions.Fakes](./unit-testing-platform-extensions-fakes.md).
+- Ensure that the project either uses the [MSTest.SDK](./unit-testing-mstest-sdk.md) or references [Microsoft.Testing.Extensions.Fakes](./microsoft-testing-platform-extensions-fakes.md).
- For .NET Framework projects, avoid setting `<PlatformTarget>AnyCPU</PlatformTarget>` as this results in NuGet not copying all files to the bin folder.
diff --git a/docs/core/testing/unit-testing-platform-integration-dotnet-test.md b/docs/core/testing/microsoft-testing-platform-integration-dotnet-test.md
similarity index 95%
rename from docs/core/testing/unit-testing-platform-integration-dotnet-test.md
rename to docs/core/testing/microsoft-testing-platform-integration-dotnet-test.md
index 4a871dbc385f1..a63fb4356b0c5 100644
--- a/docs/core/testing/unit-testing-platform-integration-dotnet-test.md
+++ b/docs/core/testing/microsoft-testing-platform-integration-dotnet-test.md
@@ -14,11 +14,11 @@ This article shows how to use `dotnet test` to run all tests in a solution (_*.s
## `dotnet test` integration
-The [dotnet test](../tools/dotnet-test.md) command is a way to run tests from solutions, projects, or already built assemblies. [Microsoft.Testing.Platform](unit-testing-platform-intro.md) hooks up into this infrastructure to provide a unified way to run tests, especially when migrating from VSTest to `Microsoft.Testing.Platform`.
+The [dotnet test](../tools/dotnet-test.md) command is a way to run tests from solutions, projects, or already built assemblies. [Microsoft.Testing.Platform](microsoft-testing-platform-intro.md) hooks up into this infrastructure to provide a unified way to run tests, especially when migrating from VSTest to `Microsoft.Testing.Platform`.
### `dotnet test` integration - VSTest mode
-`Microsoft.Testing.Platform` provides a [compatibility layer (VSTest Bridge)](./unit-testing-platform-extensions-vstest-bridge.md) to work with `dotnet test` seamlessly.
+`Microsoft.Testing.Platform` provides a [compatibility layer (VSTest Bridge)](./microsoft-testing-platform-extensions-vstest-bridge.md) to work with `dotnet test` seamlessly.
Tests can be run by running:
diff --git a/docs/core/testing/unit-testing-platform-intro.md b/docs/core/testing/microsoft-testing-platform-intro.md
similarity index 90%
rename from docs/core/testing/unit-testing-platform-intro.md
rename to docs/core/testing/microsoft-testing-platform-intro.md
index 2179a6e2726cb..352b8c467a8c6 100644
--- a/docs/core/testing/unit-testing-platform-intro.md
+++ b/docs/core/testing/microsoft-testing-platform-intro.md
@@ -45,10 +45,19 @@ The main driving factors for the evolution of the new testing platform are detai
## Run and debug tests
-`Microsoft.Testing.Platform` test projects are built as executables that can be run (or debugged) directly. There's no extra test running console or command. The app exits with a nonzero exit code if there's an error, as typical with most executables. For more information on the known exit codes, see [Microsoft.Testing.Platform exit codes](unit-testing-platform-exit-codes.md).
+`Microsoft.Testing.Platform` test projects are built as executables that can be run (or debugged) directly. There's no extra test running console or command. The app exits with a nonzero exit code if there's an error, which is typical for most executables. For more information on the known exit codes, see [Microsoft.Testing.Platform exit codes](microsoft-testing-platform-exit-codes.md).
+
+> [!TIP]
+> You can ignore a specific [exit code](./microsoft-testing-platform-exit-codes.md) using the [`--ignore-exit-code`](#options) command line option.
+>
+> You can also set command line options that apply to a specific test project in the project file using the [`TestingPlatformCommandLineArguments`](../project-sdk/msbuild-props.md#testingplatformcommandlinearguments) MSBuild property. One common use case is for test projects that have all the tests ignored, which will normally exit with exit code 8 (the test session ran zero tests). In this scenario, you can add the following under a `PropertyGroup` in your project file:
+>
+> ```xml
+> <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
+> ```
> [!IMPORTANT]
-> By default, `Microsoft.Testing.Platform` collects telemetry. For more information and options on opting out, see [Microsoft.Testing.Platform telemetry](unit-testing-platform-telemetry.md).
+> By default, `Microsoft.Testing.Platform` collects telemetry. For more information and options on opting out, see [Microsoft.Testing.Platform telemetry](microsoft-testing-platform-telemetry.md).
### [.NET CLI](#tab/dotnetcli)
@@ -212,7 +221,7 @@ The list below described only the platform options. To see the specific options
- **`--config-file`**
- Specifies a [*testconfig.json*](unit-testing-platform-config.md) file.
+ Specifies a [*testconfig.json*](microsoft-testing-platform-config.md) file.
- **`--diagnostic`**
@@ -244,7 +253,7 @@ The list below described only the platform options. To see the specific options
- **`-ignore-exit-code`**
- Allows some non-zero exit codes to be ignored, and instead returned as `0`. For more information, see [Ignore specific exit codes](./unit-testing-platform-exit-codes.md#ignore-specific-exit-codes).
+ Allows some non-zero exit codes to be ignored, and instead returned as `0`. For more information, see [Ignore specific exit codes](./microsoft-testing-platform-exit-codes.md#ignore-specific-exit-codes).
- **`--info`**
@@ -263,7 +272,7 @@ The list below described only the platform options. To see the specific options
- **`--maximum-failed-tests`**
- Specifies the maximum number of tests failures that, when reached, will stop the test run. Support for this switch requires framework authors to implement the `IGracefulStopTestExecutionCapability` capability. The exit code when reaching that amount of test failures is 13. For more information, see [Microsoft.Testing.Platform exit codes](unit-testing-platform-exit-codes.md).
+ Specifies the maximum number of tests failures that, when reached, will stop the test run. Support for this switch requires framework authors to implement the `IGracefulStopTestExecutionCapability` capability. The exit code when reaching that amount of test failures is 13. For more information, see [Microsoft.Testing.Platform exit codes](microsoft-testing-platform-exit-codes.md).
> [!NOTE]
> This feature is available in Microsoft.Testing.Platform starting with version 1.5.
@@ -284,7 +293,7 @@ The list below described only the platform options. To see the specific options
The NuGet package [Microsoft.Testing.Platform.MSBuild](https://www.nuget.org/packages/Microsoft.Testing.Platform.MSBuild) provides various integrations for `Microsoft.Testing.Platform` with MSBuild:
-- Support for `dotnet test`. For more information, see [dotnet test integration](./unit-testing-platform-integration-dotnet-test.md).
+- Support for `dotnet test`. For more information, see [dotnet test integration](./microsoft-testing-platform-integration-dotnet-test.md).
- Support for `ProjectCapability` required by `Visual Studio` and `Visual Studio Code` Test Explorers.
- Automatic generation of the entry point (`Main` method).
- Automatic generation of the configuration file.
@@ -294,7 +303,7 @@ The NuGet package [Microsoft.Testing.Platform.MSBuild](https://www.nuget.org/pac
## See also
-- [Microsoft.Testing.Platform and VSTest comparison](unit-testing-platform-vs-vstest.md)
-- [Microsoft.Testing.Platform extensions](unit-testing-platform-extensions.md)
-- [Microsoft.Testing.Platform telemetry](unit-testing-platform-telemetry.md)
-- [Microsoft.Testing.Platform exit codes](unit-testing-platform-exit-codes.md)
+- [Microsoft.Testing.Platform and VSTest comparison](microsoft-testing-platform-vs-vstest.md)
+- [Microsoft.Testing.Platform extensions](microsoft-testing-platform-extensions.md)
+- [Microsoft.Testing.Platform telemetry](microsoft-testing-platform-telemetry.md)
+- [Microsoft.Testing.Platform exit codes](microsoft-testing-platform-exit-codes.md)
diff --git a/docs/core/testing/unit-testing-platform-telemetry.md b/docs/core/testing/microsoft-testing-platform-telemetry.md
similarity index 100%
rename from docs/core/testing/unit-testing-platform-telemetry.md
rename to docs/core/testing/microsoft-testing-platform-telemetry.md
diff --git a/docs/core/testing/unit-testing-platform-vs-vstest.md b/docs/core/testing/microsoft-testing-platform-vs-vstest.md
similarity index 93%
rename from docs/core/testing/unit-testing-platform-vs-vstest.md
rename to docs/core/testing/microsoft-testing-platform-vs-vstest.md
index ad237ed369a1e..916386ec8723f 100644
--- a/docs/core/testing/unit-testing-platform-vs-vstest.md
+++ b/docs/core/testing/microsoft-testing-platform-vs-vstest.md
@@ -20,7 +20,7 @@ VSTest ships with Visual Studio, the .NET SDK, and as a standalone tool in the [
### Execute Microsoft.Testing.Platform tests
-Microsoft.Testing.Platform is embedded directly into your test project and doesn't ship any extra executables. When you run your project executable, your tests run. For more information on running Microsoft.Testing.Platform tests, see [Microsoft.Testing.Platform overview: Run and debug tests](unit-testing-platform-intro.md#run-and-debug-tests).
+Microsoft.Testing.Platform is embedded directly into your test project and doesn't ship any extra executables. When you run your project executable, your tests run. For more information on running Microsoft.Testing.Platform tests, see [Microsoft.Testing.Platform overview: Run and debug tests](microsoft-testing-platform-intro.md#run-and-debug-tests).
## Namespaces and NuGet packages
@@ -85,12 +85,12 @@ The test related arguments are VSTest specific and so need to be transformed to
|-----------------|-----------------------|
| `--test-adapter-path <ADAPTER_PATH>` | Not supported |
| `--blame` | Not supported |
-| `--blame-crash` | `--crashdump` requires [Crash dump extension](./unit-testing-platform-extensions-diagnostics.md#crash-dump) |
-| `--blame-crash-dump-type <DUMP_TYPE>` | `--crashdump-type` requires [Crash dump extension](./unit-testing-platform-extensions-diagnostics.md#crash-dump) |
+| `--blame-crash` | `--crashdump` requires [Crash dump extension](./microsoft-testing-platform-extensions-diagnostics.md#crash-dump) |
+| `--blame-crash-dump-type <DUMP_TYPE>` | `--crashdump-type` requires [Crash dump extension](./microsoft-testing-platform-extensions-diagnostics.md#crash-dump) |
| `--blame-crash-collect-always` | Not supported |
-| `--blame-hang` | `--hangdump` requires [Hang dump extension](./unit-testing-platform-extensions-diagnostics.md#hang-dump) |
-| `--blame-hang-dump-type <DUMP_TYPE>` | `--hangdump-type` requires [Hang dump extension](./unit-testing-platform-extensions-diagnostics.md#hang-dump) |
-| `--blame-hang-timeout <TIMESPAN>` | `--hangdump-timeout` requires [Hang dump extension](./unit-testing-platform-extensions-diagnostics.md#hang-dump) |
+| `--blame-hang` | `--hangdump` requires [Hang dump extension](./microsoft-testing-platform-extensions-diagnostics.md#hang-dump) |
+| `--blame-hang-dump-type <DUMP_TYPE>` | `--hangdump-type` requires [Hang dump extension](./microsoft-testing-platform-extensions-diagnostics.md#hang-dump) |
+| `--blame-hang-timeout <TIMESPAN>` | `--hangdump-timeout` requires [Hang dump extension](./microsoft-testing-platform-extensions-diagnostics.md#hang-dump) |
| `--collect <DATA_COLLECTOR_NAME>` | Depends on the data collector |
| `-d\|--diag <LOG_FILE>` | `--diagnostic` |
| `--filter <EXPRESSION>` | Depends upon the selected test framework |
diff --git a/docs/core/testing/unit-testing-mstest-configure.md b/docs/core/testing/unit-testing-mstest-configure.md
index dc05d882be0b6..25e9de1300d5c 100644
--- a/docs/core/testing/unit-testing-mstest-configure.md
+++ b/docs/core/testing/unit-testing-mstest-configure.md
@@ -14,7 +14,7 @@ MSTest is a fully supported, open-source and a cross-platform test framework tha
## Runsettings
-A *.runsettings* file can be used to configure how unit tests are being run. To learn more about the runsettings and the configurations related to the platform, you can check out [VSTest runsettings documentation](/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file) or [MSTest runner runsettings documentation](unit-testing-platform-extensions-vstest-bridge.md#runsettings-support).
+A *.runsettings* file can be used to configure how unit tests are being run. To learn more about the runsettings and the configurations related to the platform, you can check out [VSTest runsettings documentation](/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file) or [MSTest runner runsettings documentation](microsoft-testing-platform-extensions-vstest-bridge.md#runsettings-support).
### MSTest element
@@ -103,7 +103,7 @@ Each element of the file is optional because it has a default value.
## testconfig.json
-When running your tests with MSTest, you can use a `testconfig.json` file to configure the behavior of the test runner. The `testconfig.json` file is a JSON file that contains the configuration settings for the test runner. The file is used to configure the test runner and the test execution environment. For more information, refer to [Microsoft.Testing.Platform testconfig.json documentation](unit-testing-platform-config.md#testconfigjson).
+When running your tests with MSTest, you can use a `testconfig.json` file to configure the behavior of the test runner. The `testconfig.json` file is a JSON file that contains the configuration settings for the test runner. The file is used to configure the test runner and the test execution environment. For more information, refer to [Microsoft.Testing.Platform testconfig.json documentation](microsoft-testing-platform-config.md#testconfigjson).
Starting with MSTest 3.7, you can also configure MSTest runs in the same configuration file. The following sections describe the settings that you can use in the `testconfig.json` file.
diff --git a/docs/core/testing/unit-testing-mstest-migration-from-v1-to-v3.md b/docs/core/testing/unit-testing-mstest-migration-from-v1-to-v3.md
index c2a068066d6b8..de85f3587a647 100644
--- a/docs/core/testing/unit-testing-mstest-migration-from-v1-to-v3.md
+++ b/docs/core/testing/unit-testing-mstest-migration-from-v1-to-v3.md
@@ -197,8 +197,8 @@ Review deprecated attributes, and replace them with MSTest v3 alternatives where
## Code analyzers and best practices
-MSTest v3 includes built-in code analyzers for best practices, avoiding configuration pitfalls, and proper use of MSTest attributes and settings. This is automatically available when using MSTest package or MSTest.Sdk, or you can install [MSTest Analyzer package](https://www.nuget.org/packages/MSTest.Analyzers).
+MSTest v3 includes built-in code analyzers for best practices, avoiding configuration pitfalls, and proper use of MSTest attributes and settings. This is automatically available when using MSTest package or MSTest.Sdk, and starting with MSTest 3.7, MSTest.Analyzers is a transitive dependency of MSTest.TestFramework.
## Additional resources
-- [New testing platform](unit-testing-platform-intro.md)
+- [Microsoft.Testing.Platform overview](microsoft-testing-platform-intro.md)
diff --git a/docs/core/testing/unit-testing-mstest-runner-intro.md b/docs/core/testing/unit-testing-mstest-runner-intro.md
index 747de12784ebb..667bb81ab79e9 100644
--- a/docs/core/testing/unit-testing-mstest-runner-intro.md
+++ b/docs/core/testing/unit-testing-mstest-runner-intro.md
@@ -8,9 +8,9 @@ ms.date: 12/15/2023
# Microsoft.Testing.Platform support in MSTest (MSTest runner)
-MSTest supports running tests with both VSTest and [Microsoft.Testing.Platform (MTP)](./unit-testing-platform-intro.md). The support for MTP is powered by the MSTest runner, which can run tests in all contexts (for example, continuous integration (CI) pipelines, CLI, Visual Studio Test Explorer, and VS Code Text Explorer). The MSTest runner is embedded directly in your MSTest test projects, and there are no other app dependencies, such as `vstest.console` or `dotnet test`, needed to run your tests. However, you can still run your tests using `dotnet test`.
+MSTest supports running tests with both VSTest and [Microsoft.Testing.Platform (MTP)](./microsoft-testing-platform-intro.md). The support for MTP is powered by the MSTest runner, which can run tests in all contexts (for example, continuous integration (CI) pipelines, CLI, Visual Studio Test Explorer, and VS Code Text Explorer). The MSTest runner is embedded directly in your MSTest test projects, and there are no other app dependencies, such as `vstest.console` or `dotnet test`, needed to run your tests. However, you can still run your tests using `dotnet test`.
-The MSTest runner is open source and builds on the [`Microsoft.Testing.Platform`](./unit-testing-platform-intro.md) library. You can find `Microsoft.Testing.Platform` code in the [microsoft/testfx](https://github.com/microsoft/testfx/tree/main/src/Platform/Microsoft.Testing.Platform) GitHub repository. The MSTest runner comes bundled with `MSTest in 3.2.0` or newer.
+The MSTest runner is open source and builds on the [`Microsoft.Testing.Platform`](./microsoft-testing-platform-intro.md) library. You can find `Microsoft.Testing.Platform` code in the [microsoft/testfx](https://github.com/microsoft/testfx/tree/main/src/Platform/Microsoft.Testing.Platform) GitHub repository. The MSTest runner comes bundled with `MSTest in 3.2.0` or newer.
## Enable MSTest runner in an MSTest project
@@ -44,7 +44,7 @@ Consider the following example project file:
<!--
Displays error on console in addition to the log file. Note that this feature comes with a performance impact.
- For more information, visit https://learn.microsoft.com/dotnet/core/testing/unit-testing-platform-integration-dotnet-test#show-failure-per-test
+ For more information, visit https://learn.microsoft.com/dotnet/core/testing/microsoft-testing-platform-integration-dotnet-test#show-failure-per-test
-->
<TestingPlatformShowTestsFailure>true</TestingPlatformShowTestsFailure>
@@ -89,7 +89,7 @@ Consider the following example project file:
### .runsettings
-The MSTest runner supports the [runsettings](unit-testing-platform-extensions-vstest-bridge.md#runsettings-support) through the command-line option `--settings`. For the full list of supported MSTest entries, see [Configure MSTest: Runsettings](./unit-testing-mstest-configure.md#runsettings). The following commands show various usage examples.
+The MSTest runner supports the [runsettings](microsoft-testing-platform-extensions-vstest-bridge.md#runsettings-support) through the command-line option `--settings`. For the full list of supported MSTest entries, see [Configure MSTest: Runsettings](./unit-testing-mstest-configure.md#runsettings). The following commands show various usage examples.
Using `dotnet run`:
diff --git a/docs/core/testing/unit-testing-mstest-sdk.md b/docs/core/testing/unit-testing-mstest-sdk.md
index 61b13c5abef57..749ec2d8ac0f4 100644
--- a/docs/core/testing/unit-testing-mstest-sdk.md
+++ b/docs/core/testing/unit-testing-mstest-sdk.md
@@ -64,7 +64,7 @@ When you `build` the project, all the needed components are restored and install
You don't need anything else to build and run your tests and you can use the same tooling (for example, `dotnet test` or Visual Studio) used by a ["classic" MSTest project](./unit-testing-with-mstest.md).
> [!IMPORTANT]
-> By switching to the `MSTest.Sdk`, you opt in to using the [MSTest runner](./unit-testing-mstest-runner-intro.md), including with [dotnet test](./unit-testing-platform-integration-dotnet-test.md#dotnet-test---microsofttestingplatform-mode). That requires modifying your CI and local CLI calls, and also impacts the available entries of the _.runsettings_. You can use `MSTest.Sdk` and still keep the old integrations and tools by instead switching the [runner](#select-the-runner).
+> By switching to the `MSTest.Sdk`, you opt in to using the [MSTest runner](./unit-testing-mstest-runner-intro.md), including with [dotnet test](./microsoft-testing-platform-integration-dotnet-test.md#dotnet-test---microsofttestingplatform-mode). That requires modifying your CI and local CLI calls, and also impacts the available entries of the _.runsettings_. You can use `MSTest.Sdk` and still keep the old integrations and tools by instead switching the [runner](#select-the-runner).
## Select the runner
@@ -72,7 +72,7 @@ By default, MSTest SDK relies on [MSTest runner](./unit-testing-mstest-runner-in
## Extend MSTest runner
-You can customize `MSTest runner` experience through a set of [NuGet package extensions](./unit-testing-platform-extensions.md). To simplify and improve this experience, MSTest SDK introduces two features:
+You can customize `MSTest runner` experience through a set of [NuGet package extensions](./microsoft-testing-platform-extensions.md). To simplify and improve this experience, MSTest SDK introduces two features:
- [MSTest runner profile](#mstest-runner-profile)
- [Enable or disable extensions](#enable-or-disable-extensions)
@@ -89,27 +89,27 @@ You can set the profile using the property `TestingExtensionsProfile` with one o
Enables the following extensions:
- * [Code Coverage](./unit-testing-platform-extensions-code-coverage.md#microsoft-code-coverage)
+ * [Code Coverage](./microsoft-testing-platform-extensions-code-coverage.md#microsoft-code-coverage)
- * [Trx Report](./unit-testing-platform-extensions-test-reports.md#visual-studio-test-reports)
+ * [Trx Report](./microsoft-testing-platform-extensions-test-reports.md#visual-studio-test-reports)
* `AllMicrosoft` - Enable all extensions shipped by Microsoft (including extensions with a restrictive license).
Enables the following extensions:
- * [Code Coverage](./unit-testing-platform-extensions-code-coverage.md#microsoft-code-coverage)
+ * [Code Coverage](./microsoft-testing-platform-extensions-code-coverage.md#microsoft-code-coverage)
- * [Crash Dump](./unit-testing-platform-extensions-diagnostics.md#crash-dump)
+ * [Crash Dump](./microsoft-testing-platform-extensions-diagnostics.md#crash-dump)
- * [Fakes](./unit-testing-platform-extensions-fakes.md#fakes-extension) (MSTest.Sdk 3.7.0+)
+ * [Fakes](./microsoft-testing-platform-extensions-fakes.md#fakes-extension) (MSTest.Sdk 3.7.0+)
- * [Hang Dump](./unit-testing-platform-extensions-diagnostics.md#hang-dump)
+ * [Hang Dump](./microsoft-testing-platform-extensions-diagnostics.md#hang-dump)
- * [Hot Reload](./unit-testing-platform-extensions-hosting.md#hot-reload)
+ * [Hot Reload](./microsoft-testing-platform-extensions-hosting.md#hot-reload)
- * [Retry](./unit-testing-platform-extensions-policy.md#retry)
+ * [Retry](./microsoft-testing-platform-extensions-policy.md#retry)
- * [Trx Report](./unit-testing-platform-extensions-test-reports.md#visual-studio-test-reports)
+ * [Trx Report](./microsoft-testing-platform-extensions-test-reports.md#visual-studio-test-reports)
Here's a full example, using the `None` profile:
@@ -155,7 +155,7 @@ For example, to enable the crash dump extension (NuGet package [Microsoft.Testin
</Project>
```
-For a list of all available extensions, see [Microsoft.Testing.Platform extensions](./unit-testing-platform-extensions.md).
+For a list of all available extensions, see [Microsoft.Testing.Platform extensions](./microsoft-testing-platform-extensions.md).
> [!WARNING]
> It's important to review the licensing terms for each extension as they might vary.
@@ -275,7 +275,7 @@ Finally, based on the extensions profile you're using, you can also remove some
### Update your CI
-Once you've updated your projects, if you're using `MSTest runner` (default) and if you rely on `dotnet test` to run your tests, you must update your CI configuration. For more information and to guide your understanding of all the required changes, see [dotnet test integration](./unit-testing-platform-integration-dotnet-test.md#dotnet-test---microsofttestingplatform-mode).
+Once you've updated your projects, if you're using `MSTest runner` (default) and if you rely on `dotnet test` to run your tests, you must update your CI configuration. For more information and to guide your understanding of all the required changes, see [dotnet test integration](./microsoft-testing-platform-integration-dotnet-test.md#dotnet-test---microsofttestingplatform-mode).
Here's an example update when using the `DotNetCoreCLI` task in Azure DevOps:
diff --git a/docs/core/testing/unit-testing-nunit-runner-intro.md b/docs/core/testing/unit-testing-nunit-runner-intro.md
index 3e38ce0c5cb53..9babc27877976 100644
--- a/docs/core/testing/unit-testing-nunit-runner-intro.md
+++ b/docs/core/testing/unit-testing-nunit-runner-intro.md
@@ -8,9 +8,9 @@ ms.date: 05/21/2024
# Microsoft.Testing.Platform support in NUnit (NUnit runner)
-NUnit supports running tests with both VSTest and [Microsoft.Testing.Platform (MTP)](./unit-testing-platform-intro.md). The support for MTP is powered by the NUnit runner, which can run tests in all contexts (for example, continuous integration (CI) pipelines, CLI, Visual Studio Test Explorer, and VS Code Text Explorer). The NUnit runner is embedded directly in your NUnit test projects, and there are no other app dependencies, such as `vstest.console` or `dotnet test`, needed to run your tests. However, you can still run your tests using `dotnet test`.
+NUnit supports running tests with both VSTest and [Microsoft.Testing.Platform (MTP)](./microsoft-testing-platform-intro.md). The support for MTP is powered by the NUnit runner, which can run tests in all contexts (for example, continuous integration (CI) pipelines, CLI, Visual Studio Test Explorer, and VS Code Text Explorer). The NUnit runner is embedded directly in your NUnit test projects, and there are no other app dependencies, such as `vstest.console` or `dotnet test`, needed to run your tests. However, you can still run your tests using `dotnet test`.
-The NUnit runner is open source, and builds on top of [`Microsoft.Testing.Platform`](./unit-testing-platform-intro.md). You can find `Microsoft.Testing.Platform` code in [microsoft/testfx](https://github.com/microsoft/testfx/tree/main/src/Platform/Microsoft.Testing.Platform) GitHub repository. The NUnit runner is supported in NUnit3TestAdapter version 5.0 or greater. For more information, see [NUnit and Microsoft.Testing.Platform](https://docs.nunit.org/articles/vs-test-adapter/NUnit-And-Microsoft-Test-Platform.html)
+The NUnit runner is open source, and builds on top of [`Microsoft.Testing.Platform`](./microsoft-testing-platform-intro.md). You can find `Microsoft.Testing.Platform` code in [microsoft/testfx](https://github.com/microsoft/testfx/tree/main/src/Platform/Microsoft.Testing.Platform) GitHub repository. The NUnit runner is supported in NUnit3TestAdapter version 5.0 or greater. For more information, see [NUnit and Microsoft.Testing.Platform](https://docs.nunit.org/articles/vs-test-adapter/NUnit-And-Microsoft-Test-Platform.html)
## Enable NUnit runner in a NUnit project
@@ -31,7 +31,7 @@ Consider the following example project file:
<!--
Displays error on console in addition to the log file. Note that this feature comes with a performance impact.
- For more information, visit https://learn.microsoft.com/dotnet/core/testing/unit-testing-platform-integration-dotnet-test#show-failure-per-test
+ For more information, visit https://learn.microsoft.com/dotnet/core/testing/microsoft-testing-platform-integration-dotnet-test#show-failure-per-test
-->
<TestingPlatformShowTestsFailure>true</TestingPlatformShowTestsFailure>
@@ -68,7 +68,7 @@ Consider the following example project file:
### .runsettings
-The NUnit runner supports the [runsettings](unit-testing-platform-extensions-vstest-bridge.md#runsettings-support) through the command-line option `--settings`. The following commands show examples.
+The NUnit runner supports the [runsettings](microsoft-testing-platform-extensions-vstest-bridge.md#runsettings-support) through the command-line option `--settings`. The following commands show examples.
Using `dotnet run`:
diff --git a/docs/core/tools/dotnet-test.md b/docs/core/tools/dotnet-test.md
index 6b333398d0607..906dcd900764c 100644
--- a/docs/core/tools/dotnet-test.md
+++ b/docs/core/tools/dotnet-test.md
@@ -74,7 +74,7 @@ dotnet test -h|--help
The `dotnet test` command is used to execute unit tests in a given solution. The `dotnet test` command builds the solution and runs a test host application for each test project in the solution using `VSTest`. The test host executes tests in the given project using a test framework, for example: MSTest, NUnit, or xUnit, and reports the success or failure of each test. If all tests are successful, the test runner returns 0 as an exit code; otherwise if any test fails, it returns 1.
> [!NOTE]
-> `dotnet test` was originally designed to support only `VSTest`-based test projects. Recent versions of the test frameworks are adding support for [Microsoft.Testing.Platform](../testing/unit-testing-platform-intro.md). This alternative test platform is more lightweight and faster than `VSTest` and supports `dotnet test` with different command line options. For more information, see [Microsoft.Testing.Platform](../testing/unit-testing-platform-intro.md).
+> `dotnet test` was originally designed to support only `VSTest`-based test projects. Recent versions of the test frameworks are adding support for [Microsoft.Testing.Platform](../testing/microsoft-testing-platform-intro.md). This alternative test platform is more lightweight and faster than `VSTest` and supports `dotnet test` with different command line options. For more information, see [Microsoft.Testing.Platform](../testing/microsoft-testing-platform-intro.md).
For multi-targeted projects, tests are run for each targeted framework. The test host and the unit test framework are packaged as NuGet packages and are restored as ordinary dependencies for the project. Starting with the .NET 9 SDK, these tests are run in parallel by default. To disable parallel execution, set the `TestTfmsInParallel` MSBuild property to `false`. For more information, see [Run tests in parallel](../whats-new/dotnet-9/sdk.md#run-tests-in-parallel) and the [example command line later in this article](#testtfmsinparallel).
@@ -111,7 +111,7 @@ Where `Microsoft.NET.Test.Sdk` is the test host, `xunit` is the test framework.
> - Starting in .NET 7: switch `-r` to alias `--runtime` instead of `--results-directory`
> [!WARNING]
-> When using `Microsoft.Testing.Platform`, please refer to [dotnet test integration](../testing/unit-testing-platform-integration-dotnet-test.md) for the supported options. As a rule of thumbs, every option non-related to testing is supported while every testing-related option is not supported as-is.
+> When using `Microsoft.Testing.Platform`, please refer to [dotnet test integration](../testing/microsoft-testing-platform-integration-dotnet-test.md) for the supported options. As a rule of thumbs, every option non-related to testing is supported while every testing-related option is not supported as-is.
- **`--test-adapter-path <ADAPTER_PATH>`**
@@ -438,7 +438,7 @@ dotnet test -h|--help
#### Description
-With Microsoft Testing Platform, `dotnet test` operates faster than with VSTest. The test-related arguments are no longer fixed, as they are tied to the registered extensions in the test project(s). Moreover, MTP supports a globbing filter when running tests. For more information, see [Microsoft.Testing.Platform](../testing/unit-testing-platform-intro.md).
+With Microsoft Testing Platform, `dotnet test` operates faster than with VSTest. The test-related arguments are no longer fixed, as they are tied to the registered extensions in the test project(s). Moreover, MTP supports a globbing filter when running tests. For more information, see [Microsoft.Testing.Platform](../testing/microsoft-testing-platform-intro.md).
> [!WARNING]
> `dotnet test` doesn't run in environments that have test projects using both VSTest and Microsoft Testing Platform in the same solution, as the two platforms are mutually incompatible.
@@ -533,7 +533,7 @@ With Microsoft Testing Platform, `dotnet test` operates faster than with VSTest.
- **`args`**
- Specifies extra arguments to pass to the test application(s). Use a space to separate multiple arguments. For more information and examples on what to pass, see [Microsoft Testing Platform](../../../docs/core/testing/unit-testing-platform-intro.md) and [Microsoft.Testing.Platform extensions](../../../docs/core/testing/unit-testing-platform-extensions.md).
+ Specifies extra arguments to pass to the test application(s). Use a space to separate multiple arguments. For more information and examples on what to pass, see [Microsoft Testing Platform](../../../docs/core/testing/microsoft-testing-platform-intro.md) and [Microsoft.Testing.Platform extensions](../../../docs/core/testing/microsoft-testing-platform-extensions.md).
> [!NOTE]
> To enable trace logging to a file, use the environment variable `DOTNET_CLI_TEST_TRACEFILE` to provide the path to the trace file.
@@ -598,5 +598,5 @@ With Microsoft Testing Platform, `dotnet test` operates faster than with VSTest.
- [Frameworks and Targets](../../standard/frameworks.md)
- [.NET Runtime Identifier (RID) catalog](../rid-catalog.md)
-- [Microsoft.Testing.Platform](../../../docs/core/testing/unit-testing-platform-intro.md)
-- [Microsoft.Testing.Platform extensions](../../../docs/core/testing/unit-testing-platform-extensions.md)
+- [Microsoft.Testing.Platform](../../../docs/core/testing/microsoft-testing-platform-intro.md)
+- [Microsoft.Testing.Platform extensions](../../../docs/core/testing/microsoft-testing-platform-extensions.md)
diff --git a/docs/navigate/devops-testing/toc.yml b/docs/navigate/devops-testing/toc.yml
index 269529cecc943..6cf1945e7a277 100644
--- a/docs/navigate/devops-testing/toc.yml
+++ b/docs/navigate/devops-testing/toc.yml
@@ -208,51 +208,51 @@ items:
- name: Microsoft Testing Platform
items:
- name: Overview
- href: ../../core/testing/unit-testing-platform-intro.md
+ href: ../../core/testing/microsoft-testing-platform-intro.md
- name: FAQ
- href: ../../core/testing/unit-testing-platform-faq.md
+ href: ../../core/testing/microsoft-testing-platform-faq.md
- name: Comparison with VSTest
- href: ../../core/testing/unit-testing-platform-vs-vstest.md
+ href: ../../core/testing/microsoft-testing-platform-vs-vstest.md
- name: Configure the test platform
- href: ../../core/testing/unit-testing-platform-config.md
+ href: ../../core/testing/microsoft-testing-platform-config.md
- name: Extensions
items:
- name: Overview
- href: ../../core/testing/unit-testing-platform-extensions.md
+ href: ../../core/testing/microsoft-testing-platform-extensions.md
- name: Code Coverage
- href: ../../core/testing/unit-testing-platform-extensions-code-coverage.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-code-coverage.md
- name: Diagnostics
- href: ../../core/testing/unit-testing-platform-extensions-diagnostics.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-diagnostics.md
- name: Fakes
- href: ../../core/testing/unit-testing-platform-extensions-fakes.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-fakes.md
- name: Hosting
- href: ../../core/testing/unit-testing-platform-extensions-hosting.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-hosting.md
- name: Output
- href: ../../core/testing/unit-testing-platform-extensions-output.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-output.md
- name: Policy
- href: ../../core/testing/unit-testing-platform-extensions-policy.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-policy.md
- name: Test Reports
- href: ../../core/testing/unit-testing-platform-extensions-test-reports.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-test-reports.md
- name: VSTest Bridge
- href: ../../core/testing/unit-testing-platform-extensions-vstest-bridge.md
+ href: ../../core/testing/microsoft-testing-platform-extensions-vstest-bridge.md
- name: Diagnostics overview
- href: ../../core/testing/unit-testing-platform-diagnostics.md
+ href: ../../core/testing/microsoft-testing-platform-diagnostics.md
- name: Optional telemetry
- href: ../../core/testing/unit-testing-platform-telemetry.md
+ href: ../../core/testing/microsoft-testing-platform-telemetry.md
- name: Known exit codes
- href: ../../core/testing/unit-testing-platform-exit-codes.md
+ href: ../../core/testing/microsoft-testing-platform-exit-codes.md
- name: Integration with dotnet test
- href: ../../core/testing/unit-testing-platform-integration-dotnet-test.md
+ href: ../../core/testing/microsoft-testing-platform-integration-dotnet-test.md
- name: Testing platform Architecture
items:
- name: Overview
- href: ../../core/testing/unit-testing-platform-architecture.md
+ href: ../../core/testing/microsoft-testing-platform-architecture.md
- name: Capabilities
- href: ../../core/testing/unit-testing-platform-architecture-capabilities.md
+ href: ../../core/testing/microsoft-testing-platform-architecture-capabilities.md
- name: Extensions
- href: ../../core/testing/unit-testing-platform-architecture-extensions.md
+ href: ../../core/testing/microsoft-testing-platform-architecture-extensions.md
- name: Services
- href: ../../core/testing/unit-testing-platform-architecture-services.md
+ href: ../../core/testing/microsoft-testing-platform-architecture-services.md
- name: Run selective unit tests
href: ../../core/testing/selective-unit-tests.md
- name: Order unit tests
diff --git a/docs/whats-new/dotnet-docs-mod1.md b/docs/whats-new/dotnet-docs-mod1.md
index dd2031bda3a58..79236057dbf37 100644
--- a/docs/whats-new/dotnet-docs-mod1.md
+++ b/docs/whats-new/dotnet-docs-mod1.md
@@ -58,7 +58,7 @@ Welcome to what's new in the .NET docs for January 2025. This article lists some
- [Creating metrics](../core/diagnostics/metrics-instrumentation.md) - [diagnostics] Add InstrumentAdvice details to instrumentation doc
- [dotnet-coverage code coverage utility](../core/additional-tools/dotnet-coverage.md) - Update dotnet-coverage docs. Adding uninstrument command
-- [Microsoft.Testing.Platform and VSTest comparison](../core/testing/unit-testing-platform-vs-vstest.md) - Add first level info for migration off of VSTest
+- [Microsoft.Testing.Platform and VSTest comparison](../core/testing/microsoft-testing-platform-vs-vstest.md) - Add first level info for migration off of VSTest
- [Tutorial: Containerize a .NET app](../core/docker/build-container.md) - Address issues related to .NET containers
## C# language