Replies: 2 comments
-
I think that your strategy is good as-is. Cancellation token chain is designed for that reason. The testing platform own a cancellation mechanism that could be fired for different reason and we want to control that and know when it can be cancelled. Your framework does the same, you have full control to your cancellation token, you only know when it's correct to cancel. This avoid technical and logical race on cancellation and make the expectation clear and easy to foresee. After that you compose a "global" token that can be signaled from different sources, this makes the cooperative cancellation clean and easy to use. At the moment I think we should not open our token for external cancellation for the reason above. |
Beta Was this translation helpful? Give feedback.
-
I agree with @MarcoRossignoli here. Linking the 2 tokens is trivial and it allows to have good separation of concerns between cancellation provided by the framework and the platform. From a diagnostic point of view, it's also super important for both parties to be able to understand who was responsible for the cancellation (in case of bug). |
Beta Was this translation helpful? Give feedback.
-
The Microsoft testing platform gives us a cancellation token, which it is in control of cancelling. This is quite standard in .NET world.
However as a test framework, it's not uncommon for the framework to decide to cancel a test session.
Do you think it would be a good idea to allow us to access the Cancellation token source so we could cancel it ourselves?
Currently I'm creating a new cancellation token source, and having to register a callback on the framework's cancellation token, to cancel mine, and then pass mine in everywhere.
It'd feel cleaner if I could just pass through the same cancellation token all the way down, but I have no means of cancelling it myself.
Beta Was this translation helpful? Give feedback.
All reactions