Async overloads for OnMessage and When

[danielmarbach]

Customers might have tons of those tests but if they are using xunit the GetAwaiter().GetResult() calls will deadlock in certain scenarios. This introduces async variants to allow customers to move to them. This makes it possible to get the tests unstuck from deadlocking and gives them the possibility to gradually then move when the time comes to the new testable overloads

See #135 (comment)

I'm aware that this contradicts the current async method naming guideline but I think for the testing lib for this specific case this is fine

[timbussmann]

LGTM, however I'm wondering whether we shouldn't actually just remove the sync versions and release a new major version of the package?

[danielmarbach]

If I recall correctly we made them sync initially to be compatible as much as we can with the previous fluent syntax. Not against it though. It would mean more migration work but it would make them fall into the pit of success with any testing framework. Given that already two users wastes a lot of time with xunit and all other code is async as well it is probably a good strategy to make it async

[danielmarbach]

I came to the conclusion that we probably can't remove the sync overloads and only provide the async overloads. The problem is that we would expose users to the risk of having tests that pass as green but are actually red due to missing awaits.

When in one major version OnMessage or the When overloads return void or Saga<T> and then in the next major version it returns Task or Task<Saga<T>> having the surrounding method returning void will not trigger a compiler warning for missing awaits. That means the user might have after the upgrade code like this

[Fact]
public void MyTest() {
   .OnMessage();
}

which then becomes a fire & forget method

[timbussmann]

good point, didn't think about that.