Apply suggestions from code review

ghogen · web-flow · commit c921f3fe32de · 2022-08-30T15:06:43.000-07:00
diff --git a/docs/test/isolating-code-under-test-with-microsoft-fakes.md b/docs/test/isolating-code-under-test-with-microsoft-fakes.md
@@ -285,7 +285,6 @@ As long as Microsoft Fakes assemblies are present in the configured `FakesAssemb
 Distributed testing with the [vstest task](/azure/devops/pipelines/tasks/test/vstest?view=azure-devops&preserve-view=true) .NET Core and .NET 5.0 or later projects using Microsoft Fakes requires Visual Studio 2019 Update 9 Preview `20201020-06` and higher.
 
 
-
 ## Transitioning your .NET Framework test projects that use Microsoft Fakes to SDK-style .NET Framework, .NET Core, or .NET 5.0 projects or later projects
 
 You'll need minimal changes in your .NET Framework set up for Microsoft Fakes to transition to .NET Core or .NET 5.0. The cases that you would have to consider are:
@@ -301,7 +300,6 @@ You'll need minimal changes in your .NET Framework set up for Microsoft Fakes to
   ```
   This warning is because of necessary changes made in Fakes generation and can be ignored. It can be avoided by removing the assembly reference from the project file, because we now implicitly add them during the build.
 
-
 ## Microsoft Fakes support 
 ### Microsoft Fakes in older projects targeting .NET Framework (non-SDK style).
 - Microsoft Fakes assembly generation is supported in Visual Studio Enterprise 2015 and higher.
diff --git a/docs/test/live-unit-testing-start.md b/docs/test/live-unit-testing-start.md
@@ -218,7 +218,6 @@ So far, although you've written the tests for the StringLibrary class library, y
 
 When it finishes running your tests, **Live Unit Testing** displays both the overall results and the result of individual tests. In addition, the code editor window graphically displays both your test code coverage and the result for your tests. As the following illustration shows, all three tests have executed successfully. It also shows that our tests have covered all code paths in the `StartsWithUpper` method, and those tests all executed successfully (which is indicated by the green check mark, "✓"). Finally, it shows that none of the other methods in StringLibrary have code coverage (which is indicated by a blue line, "➖").
 
-
 ::: moniker range="vs-2019"
 ![The Live Test Explorer and code editor window after starting Live Unit testing](media/lut-start/vs-2019/lut-results-cs.png)
 ::: moniker-end
diff --git a/docs/test/live-unit-testing.md b/docs/test/live-unit-testing.md
@@ -179,7 +179,6 @@ There are some differences between Live Unit Testing automatically running and u
 - Live Unit Testing does not create a new application domain to run tests, but rather runs tests from the default domain. Tests run from the **Test Explorer** window do create a new application domain.
 - Live Unit Testing runs tests in each test assembly sequentially. In the **Test Explorer** window, you can choose to run multiple tests in parallel.
 
-
 ## Large solutions
 
 If your solution has 10 or more projects, Visual Studio displays the following dialog when you:
diff --git a/docs/test/manage-test-controllers-and-test-agents.md b/docs/test/manage-test-controllers-and-test-agents.md
@@ -91,7 +91,6 @@ A test agent must be set to the offline state before it can be removed.
 > [!NOTE]
 > You can’t use this procedure to remove agents that are registered to a controller as part of a lab environment.
 
-
 ### To remove a test agent from a test controller
 
 In Visual Studio 2019, you can't remove a test agent if the test controller is registered with a project.
diff --git a/docs/test/run-a-unit-test-as-a-64-bit-process.md b/docs/test/run-a-unit-test-as-a-64-bit-process.md
@@ -33,7 +33,6 @@ If you have a 64-bit machine, you can run unit tests and capture code coverage i
    From the Visual Studio menu, choose **Test**, then choose **Processor Architecture for AnyCPU projects**. Choose **x64** to run the tests as a 64-bit process.
 
 
-
    \- or -
 
    Specify `<TargetPlatform>x64</TargetPlatform>` in a *.runsettings* file. An advantage of this method is that you can specify groups of settings in different files and quickly switch between different settings. You can also copy settings between solutions. For more information, see [Configure unit tests by using a .runsettings file](../test/configure-unit-tests-by-using-a-dot-runsettings-file.md).
diff --git a/docs/test/run-unit-tests-with-test-explorer.md b/docs/test/run-unit-tests-with-test-explorer.md
@@ -40,7 +40,6 @@ When you build the test project, the tests appear in Test Explorer. If Test Expl
 
 As you run, write, and rerun your tests, the Test Explorer displays the results in a default grouping of **Project**, **Namespace**, and **Class**. You can change the way the Test Explorer groups your tests.
 
-
 You can perform much of the work of finding, organizing and running tests from the **Test Explorer** toolbar.
 
 ::: moniker range="vs-2019"
@@ -62,12 +61,10 @@ You can run all the tests in the solution, all the tests in a group, or a set of
 
 - If individual tests have no dependencies that prevent them from being run in any order, turn on parallel test execution in the settings menu of the toolbar. This can noticeably reduce the time taken to run all the tests.
 
-
 ### Run tests after every build
 
 To run your unit tests after each local build, open the settings icon in the Test Explorer toolbar and select **Run Tests After Build**.
 
-
 ## View test results
 
 As you run, write, and rerun your tests, Test Explorer displays the results in groups of **Failed Tests**, **Passed Tests**, **Skipped Tests** and **Not Run Tests**. The details pane at the bottom or side of the Test Explorer displays a summary of the test run.
@@ -137,7 +134,6 @@ You can define your own levels of the hierarchy and group by **State** and then
 |**Project**|Groups tests by the containing project.|
 |**Class**|Groups tests by the containing class.|
 
-
 ### Traits
 
 A trait is usually a category name/value pair, but it can also be a single category. Traits can be assigned to methods that are identified as a test method by the unit test framework. A unit test framework can define trait categories. You can add values to the trait categories to define your own category name/value pairs. The syntax to specify trait categories and values is defined by the unit test framework.
@@ -334,7 +330,6 @@ To filter by a different criteria:
 |**Namespace**|Searches the test namespaces for matches.|
 |**Class**|Searches the test classes names for matches.|
 
-
 To exclude a subset of the results of a filter, use the following syntax:
 
 ```
diff --git a/docs/test/test-explorer-faq.md b/docs/test/test-explorer-faq.md
@@ -28,7 +28,6 @@ ms.technology: vs-ide-test
 
 Build your project to run assembly-based discovery.
 
-
 [Real-time test discovery](https://devblogs.microsoft.com/dotnet/real-time-test-discovery/) is source-based test discovery. It can’t discover tests that use theories, custom adapters, custom traits, `#ifdef` statements, and more because they're defined at run time. A build is required for those tests to be accurately found. In Visual Studio 2017 version 15.6 and later, assembly-based discovery (the traditional discoverer) runs only after builds. This setting means real-time test discovery finds as many tests as it can while you're editing, and assembly-based discovery allows dynamically defined tests to appear after a build. Real-time test discovery improves responsiveness, but still allows you to get complete and precise results after a build.
 
 ## Test Explorer '+' (plus) symbol
@@ -127,7 +126,6 @@ To fix this error:
 
 In Visual Studio 2019, you can opt into preview features in **Tools > Options > Environment > Preview Features**.
 
-
 ## See also
 
 - <xref:Microsoft.VisualStudio.TestTools.UnitTesting?displayProperty=fullName>
diff --git a/docs/test/troubleshooting-code-coverage.md b/docs/test/troubleshooting-code-coverage.md
@@ -24,7 +24,6 @@ If you choose an **Analyze Code Coverage** command on the **Test** menu, and if
 ![Code coverage results with coloring](../test/media/vs-2019/codecoverage1.png)
 
 
-
 For more information, see [Use code coverage to determine how much code is being tested](../test/using-code-coverage-to-determine-how-much-code-is-being-tested.md).
 
 ## Possible reasons for seeing no results or old results
diff --git a/docs/test/use-ui-automation-to-test-your-code.md b/docs/test/use-ui-automation-to-test-your-code.md
@@ -434,7 +434,6 @@ You can analyze Coded UI tests using Coded UI test logs. Coded UI test logs filt
 
 **Additional options for running Coded UI tests:** You can run Coded UI tests directly from Visual Studio, as described earlier in this topic. Additionally, you can run automated UI tests using Azure Pipelines. When Coded UI tests are automated, they have to interact with the desktop when you run them, unlike other automated tests.
 
-
 - [Run unit tests with Test Explorer](../test/run-unit-tests-with-test-explorer.md)
 
 - [How to: Set up your test agent to run tests that interact with the desktop](/previous-versions/ee291332(v=vs.140))
diff --git a/docs/test/using-shims-to-isolate-your-application-from-other-assemblies-for-unit-testing.md b/docs/test/using-shims-to-isolate-your-application-from-other-assemblies-for-unit-testing.md
@@ -29,7 +29,6 @@ For an overview and "quick start" guidance, see [Isolate code under test with Mi
 
 - .NET Core, .NET 5.0 or later, and SDK-style project support previewed in Visual Studio 2019 Update 6, and is enabled by default in Update 8. For more information, see [Microsoft Fakes for .NET Core and SDK-style projects](/visualstudio/releases/2019/release-notes#microsoft-fakes-for-net-core-and-sdk-style-projects).
 
-
 ## Example: The Y2K bug
 
 Consider a method that throws an exception on January 1st of 2000:
