Remove VSTest run/discovery context from PlatformServices (Phase 6d-2)#9621
Remove VSTest run/discovery context from PlatformServices (Phase 6d-2)#9621Evangelink wants to merge 1 commit into
Conversation
60d363b to
9bd8614
Compare
…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>
9bd8614 to
9a7d463
Compare
🧪 Test quality grade — PR #962148 test methods graded across 10 files. Most changes are refactoring-only signature updates; five genuinely new test methods were added in
This advisory comment was generated automatically. Grades are heuristic
|
|
Closing as already delivered. 🎉 The entire scope of this PR (removing the VSTest run/discovery context and result object model from Verified against current
No further action needed here. |
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).