Abstract VSTest test filtering in PlatformServices (Phase 2 of platform-agnostic effort)

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[Amaury Levé (Evangelink)]

Why

Part of the multi-PR effort to make MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). This is Phase 2: test filtering.

Today the PlatformServices discovery and execution pipelines filter tests using the VSTest filter object model directly: ITestCaseFilterExpression, TestProperty, IRunContext.GetTestCaseFilter, and ITestCaseFilterExpression.MatchTestCase. This phase decouples the filtering consumers from those types so filtering is expressed as a neutral predicate over the neutral UnitTestElement model.

What

• New neutral abstractionITestElementFilter { bool Matches(UnitTestElement testElement); } in Interfaces/ITestElementFilter.cs (namespace …PlatformServices.Interface). A null filter means "no filter" → every element is included. The name is deliberately functional and carries no VSTest/TestCase/ObjectModel naming.
• TestMethodFilter stays as the single VSTest translation bridge (mirroring how Phase 1/5 left their AdapterMessageLoggerExtensions / TestResultRecorderExtensions bridges in PlatformServices). It gains GetTestElementFilter(IDiscoveryContext?, IAdapterMessageLogger, out bool filterHasError), which parses the VSTest filter exactly as before via the existing GetFilterExpression and wraps the result in a private TestElementFilter : ITestElementFilter. That wrapper is the lone place that translates the neutral element to a VSTest TestCase (element.ToTestCase()) and reuses ITestCaseFilterExpression.MatchTestCase + PropertyValueProvider.
• Consumers routed through the neutral filter:
  • Discovery: UnitTestDiscoverer.SendTestCases now uses ITestElementFilter? + filter.Matches(element).
  • Execution: TestExecutionManager.MatchTestFilter / ExecuteTestsInSourceAsync now use ITestElementFilter? + filter.Matches(test.ToUnitTestElementWithUpdatedSource(source)).
    Neither consumer references ITestCaseFilterExpression / MatchTestCase / TestProperty anymore.
• Unit tests added in TestMethodFilterTests.cs for the new wrapper (null context, no-filter context, match/non-match, parse-error → filterHasError).

No behavior change

Pure refactor. The supported-property set, the discovery-context vs run-context code paths, the parse-error handling, and the filterHasError bail-out semantics are preserved exactly:

• Discovery still enumerates the assembly and logs warnings before bailing on a filter parse error.
• Execution still early-bails before creating the isolation UnitTestRunner.

One transparent nuance (surfaced during review): in the out-of-proc VSTest path, execution now evaluates the filter against TestCase → UnitTestElement → TestCase, i.e. the same reconstruction that produces the executed element, instead of the raw incoming TestCase. For every test discovered by this adapter the round-trip is identical for all supported filter properties (FullyQualifiedName, DisplayName, Id, TestCategory, Priority, ClassName, traits), so results are unchanged in practice — the only theoretical divergence would be a foreign/older-hash Id or a non-standard fully-qualified name, which the same-adapter discover→execute flow does not produce. Reusing ToTestCase() as the single translation point was pre-approved, and the behavior is now locked by the out-of-proc --filter regression guard described under Verification.

Remaining work (future phase)

• Physically move TestMethodFilter (the VSTest parser) up into the adapter layer (MSTest.TestAdapter), building the filter at the adapter boundary and passing ITestElementFilter? into the PlatformServices entry points. That was intentionally deferred here because preserving the different per-side filterHasError semantics byte-for-byte would require threading a nullable filter + error flag through many discovery/execution signatures — an awkward change for a transitional step.
• Let the filter operate on UnitTestElement end-to-end to avoid the transitional double ToTestCase() conversion in filtered discovery.

Verification

• .\build.cmd -c Debug — green across all TFMs (net462, net8.0, net9.0, UWP, WinUI), 0 warnings / 0 errors.
• MSTestAdapter.PlatformServices.UnitTests (net8.0): 893 passed.
• MSTestAdapter.UnitTests (net8.0): 21 passed.
• Out-of-proc --filter regression guard added — new MSTest.IntegrationTests/TestCaseFilteringTests discovers then runs the DiscoverInternalsProject asset and asserts that filtering by both FullyQualifiedName and Id selects exactly the target test, in discovery and execution. The execution tests clear TestCase.LocalExtensionData to force the out-of-proc TestCase → UnitTestElement → TestCase reconstruction path this PR re-routes, so a future change cannot silently break --filter. All 4 pass; full MSTest.IntegrationTests suite green (47 passed, 1 pre-existing skip).
• Ran the expert-reviewer agent on both the refactor and the regression guard; no blocking/major findings.

⚠️ Stacked PR

This is a stacked PR on top of:

• Abstract VSTest message logging in PlatformServices (Phase 1 of platform-agnostic effort) #9548 — Phase 1 (message-logging abstraction)
• Abstract VSTest result reporting in PlatformServices (Phase 5 of platform-agnostic effort) #9550 — Phase 5 (result-recorder abstraction)

Its base branch is dev/amauryleve/vstest-decoupling-base, an integration branch that combines #9548 + #9550 (filtering touches TestMethodFilter.cs from Phase 1 and TestExecutionManager.Runner.cs from Phase 5). Until those merge, this PR's diff will include their changes. Please review/merge this after #9548 and #9550.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com