Migrate repo from VSTest to Microsoft.Testing.Platform

[Youssef1313]

Closes #<ISSUE_NUMBER>

This PR migrates from VSTest to the newer modern platform, Microsoft.Testing.Platform.

• EnableMSTestRunner is how you opt-in to MTP in MSTest.
• This requires global.json change.
• This requires updating dotnet test invocations to use the new .NET test command.
• Test projects with MTP build as standalone executables with real runnable entrypoint. So setting OutputType to Exe in test projects is also required.
• Microsoft.NET.Test.Sdk NuGet package is for VSTest so it's no longer needed.

PR Checklist

• Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
• Based off latest main branch of toolkit
• PR doesn't include merge commits (always rebase on top of our main, if needed)
• Tested code with current supported SDKs
• New component
  • Pull Request has been submitted to the documentation repository instructions. Link:
  • Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that)
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes
• Every new API (including internal ones) has full XML docs
• Code follows all style conventions

Other information

[Youssef1313]

Blocked on dotnet/sdk#51398

[Sergio0694]

Can you also pls rebase on main to remove the .NET SDK changes? 🙂

[Sergio0694]

Do we still need this?

dotnet/build/Community.Toolkit.Common.targets

Lines 19 to 22 in eb25f10

	<!-- Run tests in parallel by default -->
	<ItemGroup Condition="$(IsTestProject)">
	<AssemblyAttribute Include="Microsoft.VisualStudio.TestTools.UnitTesting.ParallelizeAttribute"/>
	</ItemGroup>

Or can we remove it in this PR if it's redundant now?

[Youssef1313]

Interesting. Only one of these are needed, assuming Community.Toolkit.Common.targets is imported for all test projects in the repo.
I would prefer the one in targets and delete the runsettings. Having the assembly attribute provides:

• More consistent experience.
• Hint to MSTest analyzer MSTEST0001 that parallelization is enabled, which will otherwise show a by-design false positive.

[Sergio0694]

Can you add a comment to explain what this is and what it does? Or a link to docs if there's any.

[RyanBuck182]

Introducing the MSTest Runner - .NET Blog

a new lightweight runner for MSTest tests

the runner does integrate with dotnet test, vstest.console, Visual Studio Test Explorer and Visual Studio Code Test Explorer to provide you with the same experience you are used to

Run tests with MSTest - Microsoft Learn

When you use MSTest SDK, by default you're opted in to using Microsoft.Testing.Platform. Alternatively, you can enable MSTest runner by adding the EnableMSTestRunner property and setting OutputType to Exe in your project file.

It seems to be another option for developers to run tests. According to the blog post, it shouldn't interfere with other methods of running tests.

Assuming this is something that we want, we should also set OutputType to Exe as described in the blog post and documentation.

[Sergio0694]

Is this because the verbosity is now detailed by default, or something else?

[Youssef1313]

The whole UX for MTP is different, and there is no -l (logger). I'm not sure what piece of info was originally intended to be looked at with detailed verbosity, maybe @nohwnd might know what VSTest exactly does under each verbosity, but anyways, I guess if there is something you don't like with the new output, we would love to know to add more customizations and/or having better defaults.

[Youssef1313]

If detailed shows passed tests, then --output detailed would be kinda the equivalent here.