Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More testing doc updates #45095

Merged
merged 10 commits into from
Mar 6, 2025
88 changes: 88 additions & 0 deletions .openpublishing.redirection.core.json
Original file line number Diff line number Diff line change
Expand Up @@ -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"
}
]
}
6 changes: 3 additions & 3 deletions docs/core/project-sdk/msbuild-props.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).

Expand Down Expand Up @@ -1515,15 +1515,15 @@ 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.

### TestingPlatformCaptureOutput

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

Expand Down
2 changes: 1 addition & 1 deletion docs/core/testing/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down Expand Up @@ -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.

Expand All @@ -115,12 +115,12 @@ 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`

An optional [test framework capability](#framework-capabilities) that allows the test framework to provide the banner message to the platform. If the message is `null` or if the capability is n't present, the platform will use its default banner message.

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.
Loading