Too easy to accidentally use Should().NotThrow() against async void lambda

[zarenner]

With the current async support in FA, it's too easy in my opinion to accidentally use .Should().NotThrow() against an async void lambda. This will result in a test that looks valid but doesn't actually test the continuation.

Example:

Action asyncFunc = async () => { await Task.Delay(5000); throw new Exception("fail"); };
asyncFunc.Should().NotThrow();
// Test (incorrectly) passes

...instead of the correct test implementation:

Func<Task> asyncFunc = async () => { await Task.Delay(5000); throw new Exception("fail"); };
asyncFunc.Should().NotThrow();
// Test (correctly) fails

I see a couple of separate but complementary possible improvements:

• Detect that the Action is an async method (e.g. action.Method.GetCustomAttribute(typeof(AsyncStateMachineAttribute)) != null), and throw. Would break anyone intentionally sending in an async void, but that seems unlikely. I don't believe it's possible to "fix" the async void method; if it was that would be another alternative.

• Add actual async [Not]ThrowAsync methods that only work on Func<Task>. Wouldn't directly prevent this mistake if NotThrow was still used, but the added Async (and await) would make it more obvious when the async assertions aren't being used. I don't know if there was a reason AsyncFunctionAssertions was designed to block instead of using async/await (possibly because it would be a bit less fluent), but personally I'd much prefer actual async assertions.

[dennisdoomen]

Option 1 sounds like a decent solution.

[jnyrup]

Can this be closed with #737 merged?