-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move startup hook tests targeting StartupHookProvider
out of hosting tests
#84338
Conversation
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsThese tests were checking how
Running locally (Windows):
Replaced tests:
The one thing the new tests don't check is that a startup hook failure means an app run failure. We do still have a test on the host side that expects failure - I think that is reasonable enough to not also need the same check for all the other possible failure points. Resolves #77805
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for using the new [Fact]
style tests! Do we want to mark this test suite as RequiresProcessIsolation, or is that not necessary?
f4b4fee
to
4cb2cae
Compare
Does the merged runner execute tests from different assemblies in parallel? I don't recall. If so, I guess technically it should be, since other things could (although unlikely) modify the |
It doesn't execute tests from different assemblies in parallel today, but it may do so in the future. |
Actually, the success-case tests do also assume that there isn't some already loaded assembly with the same name. I'll make it RequiresProcessIsolation. Thanks! |
These tests were checking how
StartupHookProvider
parses out the startup hook property, handles error cases, and handles the basic valid case of loading by an assembly path or name We don't need the startup hook scenario and process launch for that validation, so they can be moved out of hosting tests:StartupHookTests
under src/tests/Loader that targetsStartupHookProvider
directlyHostActivation.Tests
Running locally (Windows):
StartupHooks
tests went from 1.9min to 9.5s on ReleaseReplaced tests:
The one thing the new tests don't check is that a startup hook failure means an app run failure. We do still have a test on the host side that expects failure - I think that is reasonable enough to not also need the same check for all the other possible failure points.
Resolves #77805
Contributes to #77807