The infrastructure backing PublishedEvents and Scenario is currently set up in a way that it sees events published on the main test execution thread and ones spawned from that. This has been set up that way to isolate the test executions from each other in case they're run in parallel. While this is helpful in theory, it also has downsides, and we have been reported problems with that approach.
We should open up the event listeners capturing the event to not be bound to any execution thread. We should rather rely on the individual tests to formulate their completion criteria to make sure they expect events corresponding to their use case.
To enable advanced diagnosis of events potentially interfering with each other, we could dump all events and their origin per PublishedEvents / Scenario instance into a debug log after each test case execution.
The infrastructure backing
PublishedEventsandScenariois currently set up in a way that it sees events published on the main test execution thread and ones spawned from that. This has been set up that way to isolate the test executions from each other in case they're run in parallel. While this is helpful in theory, it also has downsides, and we have been reported problems with that approach.We should open up the event listeners capturing the event to not be bound to any execution thread. We should rather rely on the individual tests to formulate their completion criteria to make sure they expect events corresponding to their use case.
To enable advanced diagnosis of events potentially interfering with each other, we could dump all events and their origin per
PublishedEvents/Scenarioinstance into a debug log after each test case execution.