It would be a nice feature to add generic shorthand methods for all results that return an object:

actual.Should().BeCreatedResult<T>().Which.Should().Be(expected);

Instead of:

actual.Should().BeCreatedResult().Value.Should().BeOfType<T>().Which.Should().Be(expected);

Testers that still need to access the result object could still use the longer version, those who only need to validate the returned object could use the shorter one.

@faddiv @SoftwareWizard as it looks like we are going to need to ship a new major version to support MVC Core 3.0, are there any other breaking changes you'd like to make?

I'm not sure if it's something I'm doing, or a problem with a missing extension definition.

Our controller actions for an API project are defined as:

public async Task<ActionResult<IEnumerable<CustomerDto>>> Get()
{
    return Ok(await _mediator.Send(new GetCustomerQuery());
}

In the test:

var result = await sut.Get();

result.Should().BeOkObjectResult(); //

The code actually doesn't compile, as the Should() extension isn't detected properly. The extensions are defined as:

Should(this ActionResult actual);
Should(this IActionResult actual);

but the ActionResult is neither.

As a workaround, I've added an extension for Should(this IConvertToActionResult), and just call the .Convert() method.

Is there a better, or different approach here?

Following on from my Stack Overflow Answer for: Asserting Redirect to Action, Ben Gribaudo suggested I potentially create a PR for the mentioned Assertion extensions.

It ultimately allows something like the following:

    [Fact]
    public void ActionReturnsView_ExpectedRedirectToError_TypeMismatch()
    {
        var controller = new HomeController();

        var result = controller.Index();

        result.Should().BeRedirectAction(nameof(HomeController.Error));
    }

The implementation is:

public static class ActionResultAssertionExtensions
{
    public class ActionResultAssertions : ObjectAssertions
    {
        public new IActionResult Subject { get; }

        public ActionResultAssertions(IActionResult subject) : base(subject)
        {
            Subject = subject;
        }

        [CustomAssertion]
        public void BeRedirectAction(string actionName, string because= null, params object[] becauseArgs)
        {
            var redirectResult = AssertionExtensions.Should(Subject).BeOfType<RedirectToActionResult>().Which;

            var actual = redirectResult.ActionName;
            var expected = actionName;

            Execute.Assertion.ForCondition(actual == expected)
                .BecauseOf(because, becauseArgs)
                .FailWith("Expected {context} to redirect to {0} Action but it is redirecting to {1}", expected, actual);
        }
    }

    public static ActionResultAssertions Should(this IActionResult subject)
    {
        return new ActionResultAssertions(subject);
    }
}

Is this something you would potentially be interested in merging?

Continuation of #21

Instead of having to write

ActionResult<TestDto> result = await _controller.GetTestItemAsync(id);
result.Result.Should().BeNotFoundResult();

I'd like to write

ActionResult<TestDto> result = await _controller.GetTestItemAsync(id);
result.Should().BeNotFoundResult();

Just started using the library and quickly realized that there is only a single assertion for IActionResult<T>, BeConvertibleTo<T>.

This method doesn't help much when dealing with default responses and values, since you still have to explicitly say what the values and types are. For instance, this seems a bit unintuitive to me:

result.Should().BeConvertibleTo<ObjectResult>().Which.Value.Should().Be(myValue)

I noticed that there are quite a few checks on IActionResult. Shoudn't most of those be ported to work with ActionResult<T> as well?

@faddiv thanks for all your contributions over the last few months. I think it's time to upgrade to you a full maintainer. Are you still interested?

If yes, I'll upgrade your permissions, and then let's use this issue for any Q&A initially.

I think a good plan would be for use to work through the 3.0 release together, including you releasing it to nuget (I'll push an update to the docs so you know what to do).

Thoughts?

Appveyor failed with the following error:
Error publishing package. NuGet server returned 403: The specified API key is invalid, has expired, or does not have permission to access the specified package.
https://ci.appveyor.com/project/kevinkuszyk/fluentassertions-aspnetcore-mvc/builds/40424493