_From @jnm2 on January 28, 2017 18:5_
I've been used to scanning along the row of icons to pick out the test projects in a long list of similarly-named projects. With the new .csproj format there is nothing marking the project as a test project.
Could you either:
Or
Provide some attribute to specify which projects are intended to be run as tests.
I strongly prefer this option because it's possible to have a project that references a testing framework or even contains tests which should not be treated as a test assembly and tests (if any) should not be discovered.
For example, if I'm building an extension or utility library to extend a testing framework, I'll need to reference the testing framework but it's still not a test library and shouldn't get the icon.
For another example, if you're developing a testing framework or an extension or a utility library, it's common to have a mock test assembly which references the testing framework and contains discoverable tests, but which the IDE should not discover because those mock tests are intended to fail and timeout, etc. The mock tests are used when some real tests (in an _actual_ test project which the IDE _should_ discover) point the testing framework at the mock tests to verify that certain failures are reported and certain successes are reported, timeouts are handled, and so on.
_Copied from original issue: dotnet/roslyn-project-system#1361_
I think this should be based on the TestContainer capability @tmat suggested was to be added. The targets files of the packages that "add" test support (such as xunit, nunit, mstest, etc) should carry it and then we have a component that sets the icon based on that.
Addition of test marker from Microsoft.NET.Test.Sdk should also fix #409.
@codito What do you meam by "test marker"? UnitTestContainer capability?
@davkean Just to double-check - the projects that reference test framework nupkg that you don't want to be treated as test projects could remove the UnitTestContainer capability (assuming it's added by the test framework nupkg), correct?
Not sure yet, "capability" is one option, second option is "service guid" used by test explorer.
Are there any docs to read more on capabilities in project system? Is this just an msbuild property?
I would like "service guid" to be removed. Please use the capability. That's what they are designed for.
I think it would be best if each test framework added the capability to their nupkg, since we need to address this issue not only for CPS-based projects but for legacy projects as well.
It would be good to have this for RTM since we are using capabilities to distinguish between projects in telemetry as well.
Closing as a duplicate of #908
Lol, this was the original GitHub issue. What issue should I follow to be updated on the progress?
Oh I see, you want to track it at https://devdiv.visualstudio.com/DevDiv/_workitems?id=457621&_a=edit instead of GitHub. ¯\_(ツ)_/¯
Most helpful comment
I would like "service guid" to be removed. Please use the capability. That's what they are designed for.