-
Notifications
You must be signed in to change notification settings - Fork 264
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
Flow execution context across fixture methods when using timeout #2843
Merged
Evangelink
merged 6 commits into
microsoft:main
from
Evangelink:execution-context-timeout
May 16, 2024
Merged
Flow execution context across fixture methods when using timeout #2843
Evangelink
merged 6 commits into
microsoft:main
from
Evangelink:execution-context-timeout
May 16, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Successfully linked to Azure Boards work item(s): |
Evangelink
commented
May 15, 2024
test/IntegrationTests/MSTest.Acceptance.IntegrationTests/ThreadContextTests.cs
Show resolved
Hide resolved
nohwnd
reviewed
May 16, 2024
src/Adapter/MSTestAdapter.PlatformServices/Services/ExecutionContextService.cs
Outdated
Show resolved
Hide resolved
src/Adapter/MSTestAdapter.PlatformServices/Services/ExecutionContextService.cs
Show resolved
Hide resolved
src/Adapter/MSTestAdapter.PlatformServices/Services/ExecutionContextService.cs
Show resolved
Hide resolved
test/IntegrationTests/MSTest.Acceptance.IntegrationTests/ThreadContextTests.cs
Outdated
Show resolved
Hide resolved
test/IntegrationTests/MSTest.Acceptance.IntegrationTests/ThreadContextTests.cs
Show resolved
Hide resolved
MarcoRossignoli
previously approved these changes
May 16, 2024
✅ Successfully linked to Azure Boards work item(s): |
1 similar comment
✅ Successfully linked to Azure Boards work item(s): |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Before the timeout PR, or when no timeout is being set (runsettings or on fixture/test methods), then all methods are being called synchronously and so the state is "shared" and can be mutated by all steps. For example, when changing the culture in
AssemblyInitialize
this culture will be set for theClassInitialize
, all the way down to the test method then back to theAssemblyCleanup
.When setting up timeouts, we are starting new thread so we can stop observing the execution when the timeout expires (to overcome non-cooperative cancellation). Because of this thread creation, each thread works in isolation and its state is not preserved and flown to the other methods which is unexpected by users.
Solution
To overcome this issue, we need to manually capture and restore the right
ExecutionContext
at the right time. The logic I decided to go with is to flow top-to-bottom meaning that theAssemblyInitialize
context is flown down to theClassInitialize
... This is allowing to have a behavior similar to the one when no timeout is set.Design decision
But there is a question happening for
ClassCleanup
andAssemblyCleanup
methods where the state when there is no timeout is undeterministic as it depends on the last executed test (forClassCleanup
) and last executedClassCleanup
forAssemblyCleanup
. Although, technically, we could mimic this behavior, I think it's better to have theClassCleanup
reusing the state of left by the correspondingClassInitialize
and have theAssemblyCleanup
reusing the state left the by correspondingAssemblyInitialize
as it fixes the undeterminism and it is also closer to what happens for awaited async methods.Examples
When timeout is set:
When timeout is not set:
Fixes AB#2051896