Microsoft Testing Platform: dotnet test filtering ergonomics and discoverability differ from VSTest

[ivanball]

Describe the feedback

Migrating a multi-project solution to xUnit v3 on the Microsoft Testing Platform
(global.json runner = Microsoft.Testing.Platform), I hit ergonomic and discoverability
gaps versus the classic VSTest dotnet test workflow:

• Running a single test class or method requires passing MTP filter arguments after
  -- (for example -- -method "*Pattern*" or -- -class "*FooTests*"). This syntax
  is not surfaced by dotnet test --help and differs from the familiar VSTest
  --filter expression, so it is hard to discover.

Concretely, with a solution whose global.json sets runner: Microsoft.Testing.Platform
and xUnit v3 test projects: dotnet test --project Tests/.../X.Tests.csproj runs the
project's tests, but to run a single method I had to discover the MTP syntax
dotnet test --project ... -- -method "*Pattern*" (and -- -class "*FooTests*").
Neither form is shown by dotnet test --help, and it does not match the VSTest
--filter expression developers already know. I expected dotnet test --filter, or at
least discoverable help, to carry over.

Expected

Parity, or a clearly documented mapping, between VSTest --filter and MTP filtering
through dotnet test, plus discoverable help text for the MTP filter syntax.

Environment

• xUnit v3: 3.2.2
• Microsoft.Testing.Platform: bundled with xUnit v3 3.2.2 (global.json runner = Microsoft.Testing.Platform)
• .NET SDK: 10.0.109
• OS: Windows 11 Pro (10.0.26200)

Impact / feedback

MTP is a strong direction, but the migration friction and the discoverability gap slow
adoption for teams moving off VSTest. Better dotnet test help and documented filter
parity would smooth the transition.

[Youssef1313]

This is going to be fixed on xunit side in xunit.v3 4.x.

cc @bradwilson