[API Proposal]: Asserting the execution result of async methods. about fluentassertions HOT 11 CLOSED

I don't know what AsyncResult() is supposed do 🤔

await foo.GetSomething().AsyncResult().Should().BeWhatever();

#1478 added WithResult to help for the simple cases.
We don't want to make async variants of everything in the core library as that would double the API surface.

If you like to chain BeWhatever on Task methods have a look at https://github.com/fluentassertions/fluentassertions/blob/develop/Src/FluentAssertions/AsyncAssertionsExtensions.cs to see how you can implement it in your code base.

await foor.GetSomething().AsyncResult().Should().ThrowWhatever();

This API will not work if GetSomething() throws an exception in a sync part before entering the async part.
That exception will be thrown before reaching Should().

Some alternative available syntaxes:

var act = () => foo.GetSomething();
await act.Should()..ThrowAsyncWhatever();

using static FluentAssertions.FluentActions;

await Awaiting(() => foo.GetSomething()).ThrowAsyncWhatever();

from fluentassertions.

With AsyncReslt() it could be just the signal to FA that assertions are not for the task but its result.

I'll take a look, thanks.

from fluentassertions.

Maybe AsyncResult() can be even a trigger for source interceptor ;-)

from fluentassertions.

Why not just use Result then?

from fluentassertions.

@dennisdoomen With Result it's difficult to understand the intention. Whether we want to block and get the result of the task and then assert against it, or we want some magic to keet the assertion async and easily changeable from result vs exception assertion.

from fluentassertions.

So you are suggesting that we add overloads of all Should methods that work on the Task<T>? That would take a hell of a lot of work.

from fluentassertions.

Well... What do you think about this approach to asserting exceptions?

https://github.com/voroninp/FluentAssertionsInterception

from fluentassertions.

That's kind of the same. Adding overloads for everything. I don't see much value in that over just using Result

from fluentassertions.

Huh? Overloads for everything to assert exceptions? Why?

from fluentassertions.

Ah yes, you just introduced the Method extension method. Meh, not something I like.

await foo.GetSomething().AsyncResult().Should().BeWhatever();

This would mean that Should() or BeWhatever is going to be Task aware, which as @jnyrup said, is potentially increase (or double) the number of APIs we need to support. A simple Result should do the trick as well. And for exceptions we already have complete async support.

from fluentassertions.

Closing as there was no follow-up

from fluentassertions.