From d8208a9559afebffea77af260083040d460ade4a Mon Sep 17 00:00:00 2001 From: Alexander Batishchev Date: Fri, 10 Jan 2025 09:17:40 -0800 Subject: [PATCH 1/3] Update mstest0001.md --- docs/core/testing/mstest-analyzers/mstest0001.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/mstest-analyzers/mstest0001.md b/docs/core/testing/mstest-analyzers/mstest0001.md index 86ae122192493..d66c841fa03f8 100644 --- a/docs/core/testing/mstest-analyzers/mstest0001.md +++ b/docs/core/testing/mstest-analyzers/mstest0001.md @@ -33,7 +33,7 @@ The assembly is not marked with `[assembly: Parallelize]` or `[assembly: DoNotPa ## Rule description -By default, MSTest runs tests within the same assembly sequentially, which can lead to severe performance limitations. It is recommended to enable assembly attribute [`[assembly: Parallelize]`](/dotnet/api/microsoft.visualstudio.testtools.unittesting.parallelizeattribute) to run tests in parallel, or if the assembly is known to not be parallelizable, to use explicitly the assembly level attribute [`[assembly: DoNotParallelize]`](/dotnet/api/microsoft.visualstudio.testtools.unittesting.donotparallelizeattribute). +By default, MSTest runs tests within the same assembly sequentially, which can lead to severe performance limitations. It is recommended to enable assembly attribute [`[assembly: Parallelize]`](/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-writing-tests-attributes.md#parallelizeattribute) to run tests in parallel, or if the assembly is known to not be parallelizable, to use explicitly the assembly level attribute [`[assembly: DoNotParallelize]`](/dotnet/api/microsoft.visualstudio.testtools.unittesting.donotparallelizeattribute). The default configuration of `[assembly: Parallelize]` is equivalent to `[assembly: Parallelize(Scope = ExecutionScope.ClassLevel)]`, meaning that the parallelization will be set at class level (not method level) and will use as many threads as possible (depending on internal implementation). From a996a0b750ec0c13776d3ab93e48eb95db7dacc2 Mon Sep 17 00:00:00 2001 From: Alexander Batishchev Date: Fri, 10 Jan 2025 09:19:19 -0800 Subject: [PATCH 2/3] Fix broken link in MSTest analyzer doc --- docs/core/testing/mstest-analyzers/mstest0001.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/mstest-analyzers/mstest0001.md b/docs/core/testing/mstest-analyzers/mstest0001.md index d66c841fa03f8..0845414b64003 100644 --- a/docs/core/testing/mstest-analyzers/mstest0001.md +++ b/docs/core/testing/mstest-analyzers/mstest0001.md @@ -33,7 +33,7 @@ The assembly is not marked with `[assembly: Parallelize]` or `[assembly: DoNotPa ## Rule description -By default, MSTest runs tests within the same assembly sequentially, which can lead to severe performance limitations. It is recommended to enable assembly attribute [`[assembly: Parallelize]`](/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-writing-tests-attributes.md#parallelizeattribute) to run tests in parallel, or if the assembly is known to not be parallelizable, to use explicitly the assembly level attribute [`[assembly: DoNotParallelize]`](/dotnet/api/microsoft.visualstudio.testtools.unittesting.donotparallelizeattribute). +By default, MSTest runs tests within the same assembly sequentially, which can lead to severe performance limitations. It is recommended to enable assembly attribute [`[assembly: Parallelize]`](/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-writing-tests-attributes.md#parallelizeattribute) to run tests in parallel, or if the assembly is known to not be parallelizable, to use explicitly the assembly level attribute [`[assembly: DoNotParallelize]`](/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-writing-tests-attributes.md#donotparallelizeattribute). The default configuration of `[assembly: Parallelize]` is equivalent to `[assembly: Parallelize(Scope = ExecutionScope.ClassLevel)]`, meaning that the parallelization will be set at class level (not method level) and will use as many threads as possible (depending on internal implementation). From 26f34947ad2c9163f6d14934254eeef2a9f80e95 Mon Sep 17 00:00:00 2001 From: Alexander Batishchev Date: Fri, 10 Jan 2025 09:21:51 -0800 Subject: [PATCH 3/3] Fix broken links in MSTest analyzer docs --- docs/core/testing/mstest-analyzers/mstest0001.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/testing/mstest-analyzers/mstest0001.md b/docs/core/testing/mstest-analyzers/mstest0001.md index 0845414b64003..72ca813aa40ec 100644 --- a/docs/core/testing/mstest-analyzers/mstest0001.md +++ b/docs/core/testing/mstest-analyzers/mstest0001.md @@ -33,7 +33,7 @@ The assembly is not marked with `[assembly: Parallelize]` or `[assembly: DoNotPa ## Rule description -By default, MSTest runs tests within the same assembly sequentially, which can lead to severe performance limitations. It is recommended to enable assembly attribute [`[assembly: Parallelize]`](/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-writing-tests-attributes.md#parallelizeattribute) to run tests in parallel, or if the assembly is known to not be parallelizable, to use explicitly the assembly level attribute [`[assembly: DoNotParallelize]`](/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-writing-tests-attributes.md#donotparallelizeattribute). +By default, MSTest runs tests within the same assembly sequentially, which can lead to severe performance limitations. It is recommended to enable assembly attribute [`[assembly: Parallelize]`](../unit-testing-mstest-writing-tests-attributes.md#parallelizeattribute) to run tests in parallel, or if the assembly is known to not be parallelizable, to use explicitly the assembly level attribute [`[assembly: DoNotParallelize]`](../unit-testing-mstest-writing-tests-attributes.md#donotparallelizeattribute). The default configuration of `[assembly: Parallelize]` is equivalent to `[assembly: Parallelize(Scope = ExecutionScope.ClassLevel)]`, meaning that the parallelization will be set at class level (not method level) and will use as many threads as possible (depending on internal implementation).