diff --git a/docs/Overview.md b/docs/Overview.md index b75d2a68b8..621d3f3147 100644 --- a/docs/Overview.md +++ b/docs/Overview.md @@ -70,7 +70,7 @@ TestPlatform is also known as vstest, or by the names of the tools that use it: ## How it works? -TestPlatform consists of multiple processes that communicate over sockets, by sending JSON serialized messages. There are 4 processes that usually work together run tests: +TestPlatform consists of multiple components that communicate by sending JSON serialized messages. A classic VSTest run usually involves these processes: - Client - Runner @@ -83,7 +83,9 @@ The runner receives the request from the client, and starts an appropriate testh Testhost receives the request to run tests, and runs them via an appropriate test framework. The most often used .NET test frameworks are XUnit, MSTest and NUnit. -Datacollector observes the testhost to collect additional information about the run. +Datacollector observes the testhost to collect additional information about the run when data collection is enabled. + +Microsoft.Testing.Platform (MTP) test applications are an emerging model. For those applications, the application hosts itself and TestPlatform drives discovery and execution over the MTP protocol instead of launching a VSTest testhost. While the tests execute, the results are reported back to the runner, aggregated, and forwarded to the client. @@ -248,7 +250,7 @@ The version is negotiated between the components at the beginning of every workf #### Request, Notification and Response Ordering -The server supports processing only a single request at a time. Unless the request is [Cancel](#cancel) or [Abort](#abort) request. +The server supports processing only a single request at a time, unless the request is a Cancel or Abort request. All notifications are sent before a response is sent. @@ -293,7 +295,7 @@ The version is determined by choosing the highest common supported version. When The receiving side should remember the agreed value, and use it as the highest supported version for any downstream component. In the case above runner should send 6 to testhost, even though the runner supports versions up to 7. -The request was introduced in TestPlatform version `16.0.0`. Runners before this version are not allowed. Testhosts before this version are allowed, the version of testhost is figured out by scanning the assembly, and the request is not sent to them. Version 0 is used for communication. +The current source defines `Version0` as the lowest supported protocol version and `Version7` as the highest supported protocol version. Versions: diff --git a/docs/configure.md b/docs/configure.md index 5af8f0696e..892326a7ae 100644 --- a/docs/configure.md +++ b/docs/configure.md @@ -8,8 +8,8 @@ There are three different ways to configure various aspects of a test run. 1. **Using command line arguments** Various configuration options can be provided to the `vstest.console` or `dotnet -test` command line. For example, `--framework` can specify the runtime framework -version, or `--platform` can specify the architecture of test run (`x86` or +test` command line. For example, `--framework` can specify the target framework, +or `--platform` can specify the architecture of test run (`x86` or `x64`). 1. **Using a runsettings file** @@ -61,6 +61,10 @@ The `runsettings` file is a xml file with following sections: 1. Adapter Configuration 1. Legacy Settings +TestSettings (`*.testsettings`) are deprecated. Prefer `*.runsettings`; legacy settings +are supported only for MSTest v1 and ordered-test scenarios that explicitly opt into +legacy mode. + We will cover these sections in detail later in the document. Let's discuss few core principles for runsettings. @@ -93,8 +97,8 @@ document. x86 - - Framework40 + + net8.0 %SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar @@ -109,7 +113,7 @@ document. 10000 - + STA @@ -150,7 +154,7 @@ document. - + 4312 @@ -209,7 +213,7 @@ _Example_ x86 - .NET Framework, Version=v4.6 + net8.0 %SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar .\TestResults .\TestResults @@ -230,16 +234,19 @@ _Description_ | ResultsDirectory | string | Directory for test run reports. E.g. trx, coverage etc. | | SolutionDirectory | string | Working directory for test invocation. Results directory can be relative to this. Used by IDEs. | | MaxCpuCount | int | Degree of parallelization, spawns `n` test hosts to run tests. Default: 1. Max: Number of cpu cores. | -| TestSessionTimeout | int | Testplatform will cancel the test run after it exceeded given TestSessionTimeout in milliseconds and will show the results of tests which ran till that point. **Required Version: 15.5+.** | -| ExecutionThreadApartmentState | string | Apartment state of thread which calls adapter's RunTests and Cancel APIs. Possible values: (MTA, STA). default is STA for .NET Full and MTA for .NET Core. STA supported only for .NET Full **Required Version: 15.5+.** [More details.](#execution-thread-apartment-state) | +| TestSessionTimeout | int | Test Platform will cancel the test run after it exceeded given TestSessionTimeout in milliseconds and will show the results of tests which ran till that point. | +| ExecutionThreadApartmentState | string | Apartment state of thread which calls adapter's RunTests and Cancel APIs. Possible values: (MTA, STA). Default is STA for .NET Framework and MTA for .NET. STA is supported only for .NET Framework. [More details.](#execution-thread-apartment-state) | Examples of valid `TargetFrameworkVersion`: -* .NETCoreApp, Version=v1.0 -* .NETCoreApp, Version=v1.1 -* .NETFramework, Version=v4.5 +* net462 +* net8.0 +* net9.0 +* net10.0 +* .NETFramework,Version=v4.8 +* .NETCoreApp,Version=v8.0 -[FrameworkName]: https://msdn.microsoft.com/en-us/library/dd414023(v=vs.110).aspx +[FrameworkName]: https://learn.microsoft.com/dotnet/standard/frameworks 2. **Adapter settings** These settings are a hint to adapters to behave in a particular way. These are @@ -482,7 +489,7 @@ This section explains usage of ExecutionThreadApartmentState element in runsetti vstest.console.exe a.dll -- RunConfiguration.ExecutionThreadApartmentState=STA -dotnet test -f net46 -- RunConfiguration.ExecutionThreadApartmentState=STA +dotnet test -f net462 -- RunConfiguration.ExecutionThreadApartmentState=STA ### History @@ -490,8 +497,8 @@ In Test Platform V1 ExecutionThreadApartmentState property can be set from vstes ### Behavior -In Test platform V2 ExecutionThreadApartmentState property default value is `MTA` for .NET Core and `STA` for .NET Full. `STA` value is only supported for .NET Framework. -Warning should be shown on trying to set value `STA` for .NET Core and UAP10.0 frameworks tests. +In Test Platform V2 ExecutionThreadApartmentState property default value is `MTA` for .NET and `STA` for .NET Framework. `STA` value is only supported for .NET Framework. +Warning should be shown on trying to set value `STA` for .NET and UAP10.0 framework tests. * To support adapters which depends on thread test platform creates may need STA apartment state to run UI tests. `ExecutionThreadApartmentState` option can be used to set apartment state. Example: MSTest v1, MSTest v2 and MSCPPTest adapters. diff --git a/docs/dotnetcoretests.md b/docs/dotnetcoretests.md index 1aebadbb2c..9ec916201d 100644 --- a/docs/dotnetcoretests.md +++ b/docs/dotnetcoretests.md @@ -1,17 +1,18 @@ -For dotnet core test projects, the test platform is acquired as a nuget package (Microsoft.NET.Test.Sdk) and the runtime (testhost.dll similar to testhost.exe) is also part of the nuget package. +For SDK-style .NET test projects, the supported path is to reference +`Microsoft.NET.Test.Sdk` and run tests with `dotnet test`. -When dotnet build runs, the above mentioned packages are restored to the users' global nuget cache in the absence of any overridden config. When vstest.console.exe runs .runtimeconfig.dev.json is looked into to determine the folders to look for the testhost.dll (something like the below) in addition to the folder where the test dll is present (https://github.com/Microsoft/vstest/blob/c7472a479966a218fb0ac508ed799418eb4bfc00/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs#L374) +`dotnet test` builds the test project, restores NuGet packages, and runs the test +assembly with the test platform components provided by `Microsoft.NET.Test.Sdk`. +The VSTest testhost provider still uses the test assembly's `.deps.json` and, when +present, `.runtimeconfig.dev.json` to locate `testhost.dll`; if it cannot resolve +the package-provided testhost for a managed test assembly, it fails with guidance +to add `Microsoft.NET.Test.Sdk`. -{ - "runtimeOptions": { - "additionalProbingPaths": [ - "C:\\Users\\shivash\\.dotnet\\store\\|arch|\\|tfm|", - "C:\\Users\\shivash\\.nuget\\packages", - "C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder" - ] - } -} +In normal SDK-style projects there is no separate VSTest-specific probing-path setup +to document or configure. If you need to run tests from a copied directory or on a +machine that does not have the restored NuGet packages, publish the test project and +run from the publish output so the test assembly and its runtime dependencies are +available together. -In the case of the customer, the nuget packages aren't being restored to the paths defined in the .runtimeconfig.dev.json resulting in the testhost.dll not being determined. The locations used for the nuget packages can be determined using the below : https://learn.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders#viewing-folder-locations - -To mitigate the issue and as a general recommendation for running dot net core tests with vstest task please ask the customer to publish the test project and point to the publish location for running tests. Publish ensures all needed dependencies are present for the tests to be executed alongside the test dll in case of dot net core tests. +Current `dotnet test` usage is documented in the .NET testing guide: +. diff --git a/docs/environment-variables.md b/docs/environment-variables.md index 0809ac93f2..828da79b93 100644 --- a/docs/environment-variables.md +++ b/docs/environment-variables.md @@ -1,6 +1,6 @@ # VSTest Environment Variables -This document lists all environment variables that are understood and handled by the Visual Studio Test Platform (VSTest). These variables can be used to configure various aspects of test execution, debugging, diagnostics, and feature behavior. +This document lists environment variables that are currently handled by VSTest source code, plus a few historical variables that are called out as removed or obsolete. It is not an exhaustive list of every variable used by every adapter or hosting environment. ## Connection and Timeout Variables @@ -31,7 +31,8 @@ This document lists all environment variables that are understood and handled by - **Example**: `VSTEST_DIAG_VERBOSITY=Info` ### VSTEST_LOGFOLDER -- **Description**: Specifies the folder where test logs should be written. +- **Status**: Not used by product code under `src/`; referenced only in `test/` assets. +- **Previous description**: Specified the folder where test logs should be written. - **Example**: `VSTEST_LOGFOLDER=C:\TestLogs` ## Debug Variables @@ -91,7 +92,7 @@ This document lists all environment variables that are understood and handled by - **Example**: `VSTEST_DEBUG_ATTACHVS_PATH=C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\devenv.exe` ### VSTEST_DEBUG_NOBP -- **Description**: Disables breakpoints on executable entry points, to for more seemless debugging when using AttachVS. +- **Description**: Disables breakpoints on executable entry points for more seamless debugging when using AttachVS. - **Values**: Set to "1" to disable breakpoints - **Example**: `VSTEST_DEBUG_NOBP=1` @@ -130,14 +131,12 @@ This document lists all environment variables that are understood and handled by - **Description**: Disables artifact post-processing functionality. - **Values**: Set to any non-zero value to disable - **Example**: `VSTEST_DISABLE_ARTIFACTS_POSTPROCESSING=1` -- **Added**: Version 17.2-preview, 7.0-preview ### VSTEST_DISABLE_ARTIFACTS_POSTPROCESSING_NEW_SDK_UX - **Description**: Disables new SDK UX for artifact post-processing, showing old output format. - **Values**: Set to any non-zero value to disable - **Example**: `VSTEST_DISABLE_ARTIFACTS_POSTPROCESSING_NEW_SDK_UX=1` - **Usage**: Useful when parsing console output and need to maintain compatibility -- **Added**: Version 17.2-preview, 7.0-preview ### VSTEST_DISABLE_FASTER_JSON_SERIALIZATION - **Description**: Disables the faster JSON serialization mechanism and falls back to standard serialization. @@ -215,7 +214,7 @@ This document lists all environment variables that are understood and handled by ## Configuration and Path Variables ### VSTEST_CONSOLE_PATH -- **Description**: Specifies the path to the vstest.console executable. +- **Description**: Specifies the path to the vstest.console executable. This variable is read by the .NET SDK's `dotnet test` forwarding app (not by vstest product code under `src/` in this repo), which is why there are no `src/` references here. It is equivalent to specifying `-p:VSTestConsolePath` when using `dotnet test` with a project. - **Example**: `VSTEST_CONSOLE_PATH=C:\Tools\VSTest\vstest.console.exe` ### VSTEST_IGNORE_DOTNET_ROOT @@ -242,17 +241,11 @@ This document lists all environment variables that are understood and handled by ## Windows App Host Variables ### VSTEST_WINAPPHOST_* -- **Description**: Various environment variables related to Windows App Host configuration. +- **Description**: Prefix historically read by `DotnetTestHostManager` when launching the custom Windows app host (`testhost.exe`). The .NET SDK set `VSTEST_WINAPPHOST_DOTNET_ROOT` / `VSTEST_WINAPPHOST_DOTNET_ROOT(x86)` to support private-install scenarios; vstest forwarded them (stripping the prefix) as `DOTNET_ROOT` / `DOTNET_ROOT(x86)` so the app host could locate the runtime. Here "app host" means the native `testhost.exe` launcher — this is **not** related to the Windows App SDK, UWP, or .NET MAUI. This mechanism existed in older versions (up to ~17.7); it is **not** referenced anywhere under this repository's current `src/`, because current source sets the standard `DOTNET_ROOT` / `DOTNET_ROOT(x86)` / `DOTNET_ROOT_` variables directly. - **Pattern**: Variables following the pattern `VSTEST_WINAPPHOST_{VARIABLE_NAME}` -- **Usage**: Used internally for Windows App Host test execution scenarios ## Legacy/Experimental Variables -### VSTEST_EXPERIMENTAL_FORWARD_OUTPUT_FEATURE -- **Description**: (Deprecated) Previously used to enable output forwarding feature. -- **Status**: Replaced by VSTEST_DISABLE_STANDARD_OUTPUT_CAPTURING and VSTEST_DISABLE_STANDARD_OUTPUT_FORWARDING -- **Note**: This variable is no longer used as the feature is now enabled by default - ### VSTEST_DISABLE_PROTOCOL_3_VERSION_DOWNGRADE - **Description**: Disables automatic downgrade to protocol version 3 for compatibility. - **Values**: Set to any non-empty value to disable downgrade diff --git a/docs/extensions/datacollector-migration.md b/docs/extensions/datacollector-migration.md index 1b0bcf1e7c..fdea8319ac 100644 --- a/docs/extensions/datacollector-migration.md +++ b/docs/extensions/datacollector-migration.md @@ -5,7 +5,7 @@ This document will walk you through the changes that are required to migrate you ## Referencing DataCollector Framework Previously, `DataCollector` abstract class was present in `Microsoft.VisualStudio.QualityTools.ExecutionCommon.dll` under namespace `Microsoft.VisualStudio.TestTools.Execution`. -Now, `DataCollector`abstract class is present in Object Model. Add reference to [`Microsoft.TestPlatform.ObjectModel`](https://www.nuget.org/packages/Microsoft.TestPlatform.ObjectModel/15.5.0-preview-20170810-02) (preview) nuget package. DataCollector APIs are present under namespace `Microsoft.VisualStudio.TestPlatform.ObjectModel.DataCollection`. +Now, `DataCollector` abstract class is present in Object Model. Add reference to [`Microsoft.TestPlatform.ObjectModel`](https://www.nuget.org/packages/Microsoft.TestPlatform.ObjectModel) NuGet package. DataCollector APIs are present under namespace `Microsoft.VisualStudio.TestPlatform.ObjectModel.DataCollection`. It is recommended to target your DataCollector to netstandard, so that it can also run cross-platform, i.e. on non-Windows operating systems. For more info, refer to this [guide](./datacollector.md). diff --git a/docs/extensions/datacollector.md b/docs/extensions/datacollector.md index 67aeabfddf..b0cb053796 100644 --- a/docs/extensions/datacollector.md +++ b/docs/extensions/datacollector.md @@ -5,7 +5,7 @@ In this walkthrough, you will learn how to create your first `DataCollector` and ## Extend DataCollector The very first thing you will need to create is a Class Library project and add reference to `Microsoft.TestPlatform.ObjectModel` nuget package. -Class Library project can target Desktop clr or dotnet core clr or both frameworks. +Class Library project can target .NET Framework (for example `net462`) or .NET (for example `net8.0`, `net9.0`, or `net10.0`), or multi-target both families when the collector needs to run in both environments. > **DataCollector Assembly Naming Convention** > @@ -19,39 +19,52 @@ Class Library project can target Desktop clr or dotnet core clr or both framewor A new data collector can be implemented by extending the abstract `DataCollector` class. ```csharp +using System; +using System.IO; +using System.Xml; + using Microsoft.VisualStudio.TestPlatform.ObjectModel.DataCollection; [DataCollectorFriendlyName("NewDataCollector")] [DataCollectorTypeUri("my://new/datacollector")] public class NewDataCollector : DataCollector { - private string logFileName; - private DataCollectionEnvironmentContext context; + private string logFileName = "DataCollectorLogs.txt"; + private DataCollectionEnvironmentContext? context; + private DataCollectionSink dataSink = null!; + private DataCollectionLogger logger = null!; public override void Initialize( - System.Xml.XmlElement configurationElement, + XmlElement? configurationElement, DataCollectionEvents events, DataCollectionSink dataSink, DataCollectionLogger logger, - DataCollectionEnvironmentContext environmentContext) + DataCollectionEnvironmentContext? environmentContext) { + this.context = environmentContext; + this.dataSink = dataSink; + this.logger = logger; + events.SessionStart += this.SessionStarted_Handler; events.TestCaseStart += this.Events_TestCaseStart; - logFileName = configurationElement["LogFileName"]; + logFileName = configurationElement?["LogFileName"]?.InnerText ?? logFileName; } - - private void SessionStarted_Handler(object sender, SessionStartEventArgs args) + + private void SessionStarted_Handler(object? sender, SessionStartEventArgs args) { var filename = Path.Combine(AppContext.BaseDirectory, logFileName); File.WriteAllText(filename, "SessionStarted"); - this.dataCollectionSink.SendFileAsync(this.context.SessionDataCollectionContext, filename, true); - this.logger.LogWarning(this.context.SessionDataCollectionContext, "SessionStarted"); - } + if (context is not null) + { + dataSink.SendFileAsync(context.SessionDataCollectionContext, filename, true); + logger.LogWarning(context.SessionDataCollectionContext, "SessionStarted"); + } + } - private void Events_TestCaseStart(object sender, TestCaseStartEventArgs e) + private void Events_TestCaseStart(object? sender, TestCaseStartEventArgs e) { - this.logger.LogWarning(this.context.SessionDataCollectionContext, "TestCaseStarted " + e.TestCaseName); + logger.LogWarning(e.Context, "TestCaseStarted " + e.TestCaseName); } } ``` @@ -77,9 +90,11 @@ For supporting those scenarios, configuration xml can be passed to DataCollector ``` ```csharp -XmlElement logFileElement = configurationElement[LogFileName]; -string logFile = logFileElement != null ? logFileElement.InnerText : string.Empty; -if (!File.Exists(logFile)) +XmlElement? logFileElement = configurationElement?["LogFileName"]; +string logFile = logFileElement?.InnerText ?? "DataCollectorLogs.txt"; +string path = Path.Combine(AppContext.BaseDirectory, logFile); + +if (!File.Exists(path)) { // Create a file to write to. string createText = "Hello and Welcome" + Environment.NewLine; @@ -93,14 +108,14 @@ DataCollectors can choose to subscribe to the following events exposed by `DataC 2. TestSessionEnd : Raised when test execution session ends. 3. TestCaseStart : Raised when test case execution starts. 4. TestCaseEnd : Raised when test case execution ends. -5. TestHostLaunched : Raised when test host process has been initialized. **Note: This will be available from 15.7** +5. TestHostLaunched : Raised when test host process has been initialized. ```csharp events.SessionStart += this.SessionStarted_Handler; events.SessionEnd += this.SessionEnded_Handler; events.TestCaseStart += this.Events_TestCaseStart; events.TestCaseEnd += this.Events_TestCaseEnd; -events.TestHostLaunched += this.TestHostLaunched_Handler +events.TestHostLaunched += this.TestHostLaunched_Handler; ``` ```csharp private void Events_TestCaseStart(object sender, TestCaseStartEventArgs e) @@ -117,25 +132,33 @@ dataSink.SendFileAsync(context, filename, true); Files sent using above api get associated with session level attachments or test case level attachments based on the context passed. ### DataCollectionEnvironmentContext -DataCollector framework maintains a session level context for test exectuion session and test level contexts for each test that gets executed. +DataCollector framework maintains a session level context for test execution session and test level contexts for each test that gets executed. `DataCollectionEnvironmentContext` passed as argument in constructor has session level context that can be accessed through property `SessionDataCollectionContext`. Test case level context can be accessed through `TestCaseStartEventArgs.Context` or `TestCaseEndEventArgs.Context`. ```csharp private void Events_TestCaseStart(object sender, TestCaseStartEventArgs e) { - // Session level attachment - this.dataCollectionSink.SendFileAsync(this.context.SessionDataCollectionContext, filename, true); + // Session level attachment. environmentContext can be null, so guard before using it. + if (this.context is not null) + { + this.dataSink.SendFileAsync(this.context.SessionDataCollectionContext, filename, true); + } + // TestCase level attachment - this.dataCollectionSink.SendFileAsync(e.Context, filename, true); + this.dataSink.SendFileAsync(e.Context, filename, true); } ``` ### DataCollectionLogger DataCollectors can also log errors or warnings using `DataCollectionLogger`. ```csharp -logger.LogError(this.context.SessionDataCollectionContext, new Exception("my exception")); -logger.LogWarning(this.context.SessionDataCollectionContext, "my warning"); +// environmentContext can be null, so guard before using the session context. +if (this.context is not null) +{ + logger.LogError(this.context.SessionDataCollectionContext, new Exception("my exception")); + logger.LogWarning(this.context.SessionDataCollectionContext, "my warning"); +} ``` ### DataCollection Environment Variables @@ -143,24 +166,35 @@ DataCollectors can choose to specify information about how the test execution en E.g. setting up the Environment Variables required by profiler engine for code coverage. ```csharp +using System.Collections.Generic; + [DataCollectorFriendlyName("NewDataCollector")] [DataCollectorTypeUri("my://new/datacollector")] class NewDataCollector : DataCollector, ITestExecutionEnvironmentSpecifier { public IEnumerable> GetTestExecutionEnvironmentVariables() { + return new[] { new KeyValuePair("MY_PROFILER_SETTING", "1") }; } } ``` -Environment variables returned by the above method are set in the test execution process while bootstraping. +Environment variables returned by the above method are set in the test execution process while bootstrapping. ## Using DataCollector Once the DataCollector is compiled, it can be used to monitor test execution. There are two ways by which datacollectors can be plugged in: 1. Using /collect switch : `vstest.console.exe /collect: /testadapterpath: /testadapterpath:` +The equivalent `dotnet test` command uses `--collect` and passes adapter paths through runsettings: +`dotnet test --collect:"" -- RunConfiguration.TestAdaptersPaths=` + 2. Using runsettings : -`vstest.console.exe /settings: +`vstest.console.exe /settings:` + +or + +`dotnet test --settings ` + ```xml diff --git a/docs/quickstart.md b/docs/quickstart.md index 47bf600165..67ca4c2f42 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -1 +1,10 @@ # Quickstart Guide + +New to running .NET tests with the test platform? Start with the official .NET testing documentation: + +- [Testing in .NET](https://learn.microsoft.com/dotnet/core/testing/) — overview and getting started +- [Unit testing with `dotnet test`](https://learn.microsoft.com/dotnet/core/testing/unit-testing-with-dotnet-test) +- [`dotnet test` command reference](https://learn.microsoft.com/dotnet/core/tools/dotnet-test) +- [`vstest.console.exe` command-line options](https://learn.microsoft.com/visualstudio/test/vstest-console-options) + +For test platform internals and extensibility, see the [Overview](./Overview.md) and the [RFCs](./RFCs). diff --git a/docs/report.md b/docs/report.md index 0dee97d6bf..78dda2bbe7 100644 --- a/docs/report.md +++ b/docs/report.md @@ -125,7 +125,7 @@ Console logger is the default logger and it is used to output the test results t #### Syntax -For dotnet test or dotnet vstest: +For dotnet test or dotnet vstest (note: [`dotnet vstest` is superseded by `dotnet test`](https://learn.microsoft.com/dotnet/core/tools/dotnet-vstest), which can run assemblies directly): ```shell --logger:console[;verbosity=] diff --git a/docs/testplatform-migration-known-issues.md b/docs/testplatform-migration-known-issues.md index ab794db1f5..5850cdceca 100644 --- a/docs/testplatform-migration-known-issues.md +++ b/docs/testplatform-migration-known-issues.md @@ -7,7 +7,7 @@ Here are the current known issues you may face when running tests, along with av - **Issue:** Tests that depend on `Thread.CurrentPrincipal` may fail. This is due to change in inter process communication in Test Platform. - **Workaround:** Use an alternative like `System.Security.Principal.WindowsIdentity.GetCurrent()` -## Change in test execution processes name +## Change in test execution process name -- **Issue:** Tests that depend on the name of the currnet running process may fail. -- **Workaround:** Tests run in one of following process ```vstest.console.exe```, ```testhost.exe```, ```testhost.x86.exe``` or ```dotnet.exe``` based on run configuration (```/Platform``` and ```/Framework```). If the tests depend on the process name, then update the tests accordingly. +- **Issue:** Tests that depend on the name of the currently running process may fail. +- **Workaround:** Tests run in one of the following processes: ```vstest.console.exe```, ```testhost.exe```, ```testhost.x86.exe``` or ```dotnet.exe``` based on run configuration (```/Platform``` and ```/Framework```). If the tests depend on the process name, then update the tests accordingly.