You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We use Task.Delay in a number of tests related to the work of the message pump. The problem we have is that the pump runs until sent a terminate, and this takes time to happen. But, tests that use a Task.Delay are fragile. Fragile Tests cause us to lose our rhythm investigating them and may encourage us to work with red tests.
Describe the solution you'd like
No plan as yet, but it it worth understanding if there is a design issue here. I have no desire to change our message pump, which is key to how we build Brighter, but... it is possible that we need to look at ideas that help us test behavior without being at the mercy of the pump. Options include a replaceable pump that can be swapped out when we are not testing the pump itself, that behaves in a more controllable fashion, or imperative shell, functional core style approaches.
Describe alternatives you've considered
Rewriting the pump using something like cancellation tokens. Having seen how painful this was projects like JustSaying, I am confirmed that our choice to use a 'classic' message pump design continues to pay dividends.
Additional context
DispatcherConnectionTests are a typical example of a Fragile Test related to timings.
This discussion was converted from issue #1272 on February 16, 2021 09:43.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is your feature request related to a problem? Please describe.
We use Task.Delay in a number of tests related to the work of the message pump. The problem we have is that the pump runs until sent a terminate, and this takes time to happen. But, tests that use a Task.Delay are fragile. Fragile Tests cause us to lose our rhythm investigating them and may encourage us to work with red tests.
Describe the solution you'd like
No plan as yet, but it it worth understanding if there is a design issue here. I have no desire to change our message pump, which is key to how we build Brighter, but... it is possible that we need to look at ideas that help us test behavior without being at the mercy of the pump. Options include a replaceable pump that can be swapped out when we are not testing the pump itself, that behaves in a more controllable fashion, or imperative shell, functional core style approaches.
Describe alternatives you've considered
Rewriting the pump using something like cancellation tokens. Having seen how painful this was projects like JustSaying, I am confirmed that our choice to use a 'classic' message pump design continues to pay dividends.
Additional context
DispatcherConnectionTests are a typical example of a Fragile Test related to timings.
Beta Was this translation helpful? Give feedback.
All reactions