Fluentassertions: Should throw API question/proposition

[maxcherednik]

Description

Currently the usage of the Should.Throw construction in the context of the async method looks like this:

public void SomeTestMethod()
{
   Func<Task> f = async () =>
   {
          await Fail();
   };

  f.Should().Throw<SomeException>();
}

What if we had more idiomatic(in terms of the C# language) API of the Should().Throw() construction:

public async Task SomeTestMethod()
{
   Func<Task> f = async () =>
   {
          await Fail();
   };

  await f.Should().Throw<SomeException>();
}

Pros:

1. Performance
   async/await all the way - in the context of a usual unit test the benefit might be not visible, since most of the mocked dependencies will be in-memory, there will be no io, hence no boost at all.
   On the other hand, we use this library on a slightly broader scope - we do have tests, which might have an actual db write/read and the xunit runner, for instance, which runs lots of tests like this in parallel, could benefit from this by not holding a running thread.

2. Easier to implement - async all the way, no .Result or .Wait(), no tricks to overcome potential deadlock when blocking on the async pipeline.

Cons:
It seems like a breaking change

[peterekepeter]

Running async actions is definitely useful for integration testing.

I'm sure a lot of folk have a lot of tests that don't want to rewrite, so maybe instead of breaking changes introduce a new ShouldAsync for async functions?

I dont see why Fail would need to be async as all it does is to throw an exception (not depending on any IO)

[dennisdoomen]

Or a Should().ThrowAsync<Exception>()?