…ervices
Squashed rebase of the vstest-decoupling PlatformServices stack onto main.
Phases 1, 2 and 5 already landed on main via #9548/#9567/#9550; this commit
carries the remaining net-new work:
- Phase 3 (#9566): abstract the VSTest discovery sink (IUnitTestElementSink).
- Phase 4 (#9572): abstract VSTest execution input.
- Phase 6a (#9576): neutralize deployment input (DeploymentContext).
- Phase 6b (#9579): neutralize test result recording (ITestResultRecorder).
- Phase 6c (#9585): neutralize test message logging.
- Phase 6c2: neutralize run-settings input in the host layer (settingsXml).
- Phase 6d-1: move test-case filter parsing to the adapter boundary
(ITestElementFilterProvider / TestElementFilterProvider).
- Phase 6d-2: remove IRunContext/IDiscoveryContext from PlatformServices.
- Phase 6e-1 (#9622): remove IFrameworkHandle from the execution engine.
- Phase 6e-2 (#9623): relocate VSTest logger/sink bridges to the adapter.
- Phase 6e-3a (#9624): neutralize the trait type on UnitTestElement.
Result: MSTestAdapter.PlatformServices no longer references the VSTest
run/discovery context or result object model; those types live only at the
MSTest.TestAdapter boundary.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Phase 6d-2 of the PlatformServices platform-agnostic initiative
Removes the VSTest
IRunContext/IDiscoveryContexttypes entirely fromMSTestAdapter.PlatformServicesby extracting the only two members ever read off them —.RunSettings.SettingsXmland.TestRunDirectory— at the adapter boundary and passing them in.What changed
DeploymentContext(the{ TestRunDirectory, RunSettingsXml }DTO from 6a) is un-guarded and becomes the single execution-inputs carrier.MSTestExecutorbuildsnew DeploymentContext(runContext?.TestRunDirectory, runContext?.RunSettings?.SettingsXml)and injects it intoTestExecutionManager.RunTestsAsync/ExecuteTestsAsync/ExecuteTestsInSourceAsync/Deploy.MSTestDiscovererpasses the run-settings XML string intoUnitTestDiscoverer.DiscoverTests/DiscoverTestsInSource;MSTestDiscovererHelpers.InitializeDiscoveryandMSTestSettings.PopulateSettingstakestring? settingsXml.No behavior change
Only
.SettingsXmland.TestRunDirectorywere ever read, so this is byte-for-byte. ThePopulateSettingsguard change is provably equivalent (RunSettingsFileHasMSTestSettings(null)returns false).IRunContext/IDiscoveryContextare now absent from PlatformServices code (doc comments only); the remainingObjectModel.Adaptersurface is theIFrameworkHandle-backed deploy/recorder/logger handles.Verification
Full build all TFMs; PlatformServices.UnitTests 897/935; MSTestAdapter.UnitTests 21; MSTest.IntegrationTests 47 pass/1 skip (incl.
TestCaseFilteringTests+ deployment); PlatformServices.Desktop.IntegrationTests 15 (AppDomain deployment). Expert-reviewer: no material findings, definitive byte-for-byte verdict.Base / stacking
Stacked on Phase 6d-1 (#9591). Base =
dev/amauryleve/vstest-decoupling-filter; review/merge after #9591.Remaining
6e (relocate bridges + deep UnitTestElement<->TestCase + EngineConstants; close #9568/#9573), then 7 (drop the ObjectModel/ObjectModel.Utilities PackageReference + guard test).