I am trying to check an async method throws concrete exception.
For that I am using MSTEST and FluentAssertions 2.0.1.
I have checked this Discussion on Codeplex and to see how it works with async-exception methods this another one link about FluentAssertions async tests:
After a while trying to work with my 'production' code I have switched off to the Fluentassertions fake aync class and my resulting code is like this (put this code inside a [TestClass]
:
[TestMethod]
public void TestThrowFromAsyncMethod()
{
var asyncObject = new AsyncClass();
Action action = () =>
{
Func<Task> asyncFunction = async () =>
{
await asyncObject.ThrowAsync<ArgumentException>();
};
asyncFunction.ShouldNotThrow();
};
}
internal class AsyncClass
{
public async Task ThrowAsync<TException>()
where TException : Exception, new()
{
await Task.Factory.StartNew(() =>
{
throw new TException();
});
}
public async Task SucceedAsync()
{
await Task.FromResult(0);
}
}
The problem is that ShouldNotThrow
is not valid:
ShouldNotThrow method is not recognised by the code. If I try to compile, it gives me this error: 'System.Func' does not contain a definition for 'ShouldNotThrow' and the best extension method overload 'FluentAssertions.AssertionExtensions.ShouldNotThrow(System.Action, string, params object[])' has some invalid arguments
Thanks.
SOLUTION
2.0.1 FA version doesn't support this ShouldNotThrow
functionality and it will be included in the next reléase 2.1 (near next week).
Note: ShouldThrow is already supported in 2.0.1 versión.
If you look at AssertionExtensions.cs class you will see that the ShouldNotThrow extension method on Func is only defined for net45 or winrt compilation targets.
Check this:
Also after doing this, I think you need to call the action method to do the assertion, otherwise the inner lambda will not be called:
You don't need the encompassing Action. That is only used in the unit tests to verify that the API is throwing the right exception. This should be sufficient:
Unfortunately the ShoudlNotThrow() on a Func is missing from .NET 4.5. I've fixed this in release 2.1 (currently dogfooding).