Refactor and split up tests.targets and companion files

[ViktorHofer]

We should refactor our testing framework which consists of tests.targets and companion files like CodeCoverage.targets, PerfTesting.targets and others. I'm not thinking about a full blown separation of concerns to make it usable by a wide variety of projects but about making targeted enhancements that currently cause issues and slow down improvements. Afaik, Jose already started refactoring the test framework as we plan to move it to arcade.

• Split targets up into props and targets to make some properties available during a project build as targets are usually imported at last either manually (non-sdk) or automatically (sdk). One example which ran into this issue is https://github.com/dotnet/corefx/issues/32420.
• Conditionally import props and targets. Today we import a lot of different feature target files into the main tests.targets without first checking if that feature is needed. That leads to unexpected behaviors and pollutes the property and target bag. Example: CodeCoverage msbuild files should only be imported if /p:Coverage=true is passed in and corresponding conditions met: https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/tests.targets#L101
• Extract targets from test features that are not project dependent. Example: PerfTesting.targets contains a target which runs after the TestAllProjects target which means not on a per project basis but after the whole test suite is tested. This makes it tough to conditionally import these test feature files as that target won't be imported in the main project which builds all the projects. A solution would be to manually import that target or to extract such "static" targets out: https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/PerfTesting.targets#L102.

An example structure for the test framework files, related to task 1:

• tests.props
• tests.coverage.props
• tests.performance.props
• tests.publish.props
• tests.targets
• tests.coverage.targets
• tests.performance.targets
• tests.publish.targets

cc @danmosemsft @joperezr @safern @weshaggard

[weshaggard]

We should do this as part of moving the testing infrastructure from BuildTools to Arcade.

[ViktorHofer]

I would be very happy to help with that task. @joperezr what's the status of your work regarding the move of the test framework to arcade?

[ViktorHofer]

Done with the arcade work.