Microsoft.Testing.Platform vs Microsoft.TestPlatform.TestHost package

[nithinbandaru1]

Description

When I create a test project that can be MSTest or NUnit or xUnit, Microsoft.TestPlatform.TestHost package dependency is added as part of Microsoft.NET.Test.Sdk package.

But according to this documentation (https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-platform-vs-vstest) it sounds like Microsoft.Testing.Platform would be added as dependency as quoted form page below.

Execute VSTest tests
VSTest ships with Visual Studio, the .NET SDK, and as a standalone tool in the Microsoft.TestPlatform NuGet package. VSTest uses a runner executable to run tests, called vstest.console.exe, which can be used directly or through dotnet test.

Execute Microsoft.Testing.Platform tests

Microsoft.Testing.Platform is embedded directly into your test project and doesn't ship any extra executables. When you run your project executable, your tests run. For more information on running Microsoft.Testing.Platform tests, see Microsoft.Testing.Platform overview: Run and debug tests.

1. I was also not able to find any DLL being compiled called Microsoft.Testing.Platform or having as sub package under Microsoft.TestPlatform.TestHost or Microsoft.NET.Test.Sdk, When I search nuget I see Microsoft.Testing.Platform package active so not really sure what's happening here. It would be great if some details are provided?

2. Microsoft.NET.Test.Sdk - Isn't this fit more at csproj root xml element. Looks bit out of place to me.

3. It looks like Microsoft.Testing.Platform is lightweight portable build compared to Microsoft.TestPlatform, So, what does this exactly means, what is missing compared to Microsoft.TestPlatform? Some windows only components?

4. Is it Microsoft.Testing.Platform that will do the finding of available adaptors and have methods to call the adaptors to get test list/discover tests, run tests by calling adaptor runner part of code? If that is the case what is its replacement in Microsoft.NET.Test.Sdk?

5. Is it Microsoft.Testing.Platform that can be used as a nuget dependency for building custom explorers/run initiators like for example instead of console UI like vstest.console.exe or dotnet test, I want to build a Windows UI application. I that case can I use this dependency to interact with adaptors and discover, run tests?

Steps to reproduce

Creating empty project should be sufficient.

Expected behavior

Probably only Microsoft.Testing.Platform should be added as dependency? Not really sure.

Actual behavior

Microsoft.NET.Test.Sdk is added as dependency with Microsoft.Coverage and Microsoft.TestPlatform.TestHost as sub packages.

Diagnostic logs

Not relevant

Environment

Not relevant

[nohwnd]

Hello, could please you highlight the text in the quote above that makes you think test.sdk should have Testing.Platform as dependency?

1. You are not finding it most likely because you are not using MSTest. Or you are not using MSTest project generated by net9.0 template. Testing.Platform (Testing.Platform not TestPlatform) is shipped under MSTest nuget package, and also together with the most recent NUnit, but is not shipped with XUnit, and it is not shipped with Microsoft.NET.Test.SDK

2. Yes that name is similar to the name of the modern SDK used in modern csproj files, but it does something quite different. We inherited the product when it had this name already, and the intent probably was that it will become msbuild SDK but it never did, not would it make sense to make it one.

3. The new testing platform is focusing on having less dependencies, for example vstest requires that you have a working networking stack, or it has hard dependency on newtonsoft.json, the new platform does not have that. It is also more portable, because everything is installed via a nuget package, and there are no extra components you would need to run tests, e.g. extra tools package for getting vstest.console, or .NET SDK.

We also focus on performance to add the least amount of overhead to your test running (e.g. having less processes starting, have client directly in process rather than having to start another exe just to forward messages), having the whole stack async-first instead of allocating many threads etc.

4. Testing.Platform does not scan your dlls for available adaptors, this mechanism changed to be done during build time. Microsoft.Testing.Platform.MSBuild package uses msbuild targets and "source generator" to emit all the extensions that were referenced into your Main method. This is faster and less error prone. You can also wire all this by yourself by providing the Main method and all the callbacks yourself, but this is necessary only if you are trying to run on low level.

There is no alternative for it in Microsoft.NET.Test.SDK, they are two completely different things. But you can install them all together e.g. how MSTest package does it now, to ensure the maximum amount of backwards compatibility, so you can switch between running via the new testing platform, and the old vstest (TestPlatform).

5. Yes, the platform is hostable in various places, not just a console application. You could write a graphical app that will rely on the testing platform as a test runner, and will report the tests in the UI. If you plan to do this please tell me more about what exactly you want to achieve, because this can go into two very different directions: a multipurpose test runner that supports various frameworks (this is not very well aligned with testing.platform), or UWP app (for example) that will run UWP tests, and will report them in nice view (this is aligned with testing.platform).