Check ReturnsAsync method for null arguments.

[voroninp]

I make same mistake again and again.

If you call ReturnsAsync(null) compiler selects the overload which accepts a function, not a value. As a result test fails with NullReferenceException which is very confusing.

It would be nice if method checked that function is not null and threw ArgumentException with the message giving a hint to the reason of this oddity.

[stakx]

@voroninp, thanks for mentioning this. IIRC, we already have something in place to deal with this problem in the regular Returns, I guess we forgot to do the same in ReturnsAsync. I'll take a look later today.

[stakx]

I should add that the fix will probably be that it won't throw an exception; instead, it will internally redirect the null argument to the ReturnsAsync overload that you probably intended to call.

[voroninp]

@stakx Yes, even better, thanks.

[stakx]

If you call ReturnsAsync(null) compiler selects the overload which accepts a function, not a value

@voroninp: I cannot actually reproduce this. Here's my attempt, but I get a compile-time error:

public interface IX
{
    Task<string> GetStringAsync();
}

var mock = new Mock<IX>();
mock.Setup(x => x.GetStringAsync()).ReturnsAsync(null);
//                                  ^^^^^^^^^^^^
//                                     CS0121

CS0121: The call is ambiguous between the following methods or properties:

• ReturnsExtensions.ReturnsAsync<TMock, TResult>(IReturns<TMock, Task<TResult>>, TResult)
• ReturnsExtensions.ReturnsAsync<TMock, TResult>(IReturns<TMock, Task<TResult>>, Func<TResult>)

Can you post a very short code example like the above that demonstrates the incorrect overload selection?

[voroninp]

@stakx Make return type to be object, not string.

[voroninp]

@stakx When prototyping and testing I usually start with object =)

[stakx]

When prototyping and testing I usually start with object =)

Right you are, perhaps I should, too. 😆