Address review comments

Author: Evangelink

docs/core/testing/mstest-analyzers/mstest0056.md

@@ -33,7 +33,7 @@ A test method attribute uses a string constructor argument instead of the <xref:
 
 ## Rule description
 
-When specifying a custom display name for a test method, you should use the <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute.DisplayName> property instead of passing a string as a constructor argument. This ensures consistent usage across the MSTest framework and improves code readability.
+When specifying a custom display name for a test method, you should use the <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute.DisplayName> property instead of passing a string as a constructor argument. In MSTest 4.0 and later, the string constructor argument is used for source information (caller file path) rather than display name, which is a breaking change from MSTest 3.x. Using the `DisplayName` property ensures your code works correctly and avoids potential confusion.
 
 ```csharp
 [TestClass]
@@ -65,7 +65,7 @@ public class TestClass
 
 ## When to suppress warnings
 
-Do not suppress warnings from this rule. Using the `DisplayName` property is the correct and recommended way to specify custom display names for test methods.
+Do not suppress warnings from this rule. Using the `DisplayName` property is the only way to specify custom display names for test methods. If your intent is to explicitly pass a value for the caller file path parameter instead of setting a display name, you can suppress this warning, but this is rarely needed.
 
 ## Suppress a warning
 

docs/core/testing/mstest-analyzers/mstest0057.md

@@ -33,7 +33,7 @@ A custom <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute>
 
 ## Rule description
 
-When creating custom test method attributes that derive from <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute>, you should propagate source information using caller information attributes. This allows MSTest to correctly track the source file and line number for test methods, improving diagnostics and test result reporting.
+When creating custom test method attributes that derive from <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute>, you should propagate source information using caller information attributes. This allows MSTest to correctly track the source file and line number for test methods, improving diagnostics, test result reporting, and Test Explorer behavior.
 
 ```csharp
 public class MyTestMethodAttribute : TestMethodAttribute

docs/core/testing/mstest-analyzers/mstest0058.md

@@ -49,34 +49,27 @@ public class TestClass
             // Code that might throw.
             DoSomethingThatMightThrow();
         }
-        catch
+        catch (Exception ex)
         {
-            Assert.Fail("Exception was thrown"); // Violation
+            Assert.AreEqual("Expected error message", ex.Message); // Violation
         }
     }
 }
 ```
 
 ## How to fix violations
 
-Use `Assert.ThrowsException` or related assertion methods to test for exceptions.
+Use `Assert.Throws`, `Assert.ThrowsExactly` or related assertion methods to test for exceptions.
 
 ```csharp
 [TestClass]
 public class TestClass
 {
     [TestMethod]
-    public void TestMethod_ThrowsException()
+    public void TestMethod_ThrowsExceptionWithExpectedMessage()
     {
-        Assert.Throws<InvalidOperationException>(() => DoSomethingThatMightThrow());
-    }
-
-    [TestMethod]
-    public void TestMethod_DoesNotThrow()
-    {
-        // If no exception is expected, just call the method directly
-        DoSomethingThatMightNotThrow();
-        // Add positive assertions here
+        InvalidOperationException exception = Assert.Throws<InvalidOperationException>(() => DoSomethingThatMightThrow());
+        Assert.AreEqual("Expected error message", exception.Message);
     }
 }
 ```

docs/core/testing/mstest-analyzers/mstest0059.md

@@ -33,12 +33,12 @@ An assembly contains both <xref:Microsoft.VisualStudio.TestTools.UnitTesting.Par
 
 ## Rule description
 
-The <xref:Microsoft.VisualStudio.TestTools.UnitTesting.ParallelizeAttribute> and <xref:Microsoft.VisualStudio.TestTools.UnitTesting.DoNotParallelizeAttribute> attributes are mutually exclusive. Having both attributes in the same assembly creates conflicting configuration that can lead to unpredictable test execution behavior. You should choose one parallelization strategy for your test assembly.
+The <xref:Microsoft.VisualStudio.TestTools.UnitTesting.ParallelizeAttribute> and <xref:Microsoft.VisualStudio.TestTools.UnitTesting.DoNotParallelizeAttribute> attributes are mutually exclusive at the assembly level. When both attributes are applied to the same assembly, tests run sequentially. This conflicting configuration indicates unclear intent and should be resolved by choosing one parallelization strategy for your test assembly.
 
 ```csharp
 using Microsoft.VisualStudio.TestTools.UnitTesting;
 
-[assembly: Parallelize(Workers = 2, Scope = ExecutionScope.MethodLevel)] // Violation
+[assembly: Parallelize(Workers = 0, Scope = ExecutionScope.MethodLevel)] // Violation
 [assembly: DoNotParallelize]
 ```
 
@@ -51,7 +51,7 @@ If you want parallel execution:
 ```csharp
 using Microsoft.VisualStudio.TestTools.UnitTesting;
 
-[assembly: Parallelize(Workers = 2, Scope = ExecutionScope.MethodLevel)]
+[assembly: Parallelize(Workers = 0, Scope = ExecutionScope.MethodLevel)]
 ```
 
 If you want sequential execution:
@@ -62,6 +62,33 @@ using Microsoft.VisualStudio.TestTools.UnitTesting;
 [assembly: DoNotParallelize]
 ```
 
+If you want to enable parallelization at the assembly level but disable it for specific classes or methods, apply `Parallelize` at the assembly level and `DoNotParallelize` at the class or method level:
+
+```csharp
+using Microsoft.VisualStudio.TestTools.UnitTesting;
+
+[assembly: Parallelize(Workers = 0, Scope = ExecutionScope.MethodLevel)]
+
+[DoNotParallelize]
+[TestClass]
+public class SequentialTests
+{
+    [TestMethod]
+    public void Test1() { }
+}
+
+[TestClass]
+public class ParallelTests
+{
+    [TestMethod]
+    public void Test2() { }
+    
+    [DoNotParallelize]
+    [TestMethod]
+    public void Test3() { }
+}
+```
+
 ## When to suppress warnings
 
 Do not suppress warnings from this rule. Having both attributes creates ambiguous test configuration that should be resolved.

docs/core/testing/mstest-analyzers/mstest0060.md

@@ -33,14 +33,14 @@ A test method has multiple <xref:Microsoft.VisualStudio.TestTools.UnitTesting.Te
 
 ## Rule description
 
-A test method should have only one attribute that derives from <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute>. Having multiple test method attributes (such as `[TestMethod]` and `[DataTestMethod]`) on the same method can lead to unexpected behavior and test execution issues.
+A test method should have only one attribute that derives from <xref:Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute>. Having multiple test method attributes (such as `[TestMethod]` and `[UITestMethod]`) on the same method causes only one attribute to be used (the first one returned by reflection), which can be confusing and lead to unintended test execution.
 
 ```csharp
 [TestClass]
 public class TestClass
 {
     [TestMethod]
-    [DataTestMethod] // Violation
+    [UITestMethod] // Violation
     public void TestMethod1()
     {
         // Test code
@@ -66,7 +66,7 @@ public class TestClass
 
 ## When to suppress warnings
 
-Do not suppress warnings from this rule. Having multiple test method attributes creates ambiguous test configuration that should be resolved.
+Do not suppress warnings from this rule. Having multiple test method attributes creates ambiguous test configuration where only one attribute is used, which can cause confusion about which test behavior is actually applied.
 
 ## Suppress a warning
 

docs/core/testing/mstest-analyzers/mstest0062.md

@@ -33,7 +33,7 @@ A test method has parameters marked with `out` or `ref` modifiers.
 
 ## Rule description
 
-Test methods should not have `out` or `ref` parameters because these modifiers are incompatible with data-driven testing. Data sources provide values to test methods through standard parameter passing, and the `out` and `ref` modifiers create conflicts with this mechanism. Using regular parameters makes tests more maintainable and compatible with parameterized test features.
+Test methods should not have `out` or `ref` parameters. MSTest is responsible for calling test methods, and it never reads the values that are passed by reference after the test method finishes. These modifiers are misleading because they suggest the test method returns values that will be used, but MSTest never uses them after the test completes.
 
 ```csharp
 [TestClass]
@@ -56,7 +56,7 @@ Remove the `out` and `ref` modifiers from test method parameters.
 public class TestClass
 {
     [TestMethod]
-    public void TestMethod(string s, string s2)
+    public void TestMethod()
     {
         // Test code
     }
@@ -74,10 +74,11 @@ public class TestClass
     {
         // Arrange
         string result;
+        string passedByRef = "some value";
         var instance = new MyClass();
 
         // Act
-        bool success = instance.TryGetValue(out result);
+        bool success = instance.TryGetValue(out result, ref passedByRef);
 
         // Assert
         Assert.IsTrue(success);
@@ -92,7 +93,7 @@ For data-driven tests:
 [TestClass]
 public class TestClass
 {
-    [DataTestMethod]
+    [TestMethod]
     [DataRow("input1", "expected1")]
     [DataRow("input2", "expected2")]
     public void TestMethod(string input, string expected)
@@ -113,7 +114,7 @@ public class TestClass
 
 ## When to suppress warnings
 
-You might suppress this warning if you have a specific advanced scenario that requires `out` or `ref` parameters. However, this is rare, and you should consider alternative test designs first.
+Do not suppress warnings from this rule. There is no valid scenario where test methods should use `out` or `ref` parameters.
 
 ## Suppress a warning