fluentassertions / fluentassertions.aspnetcore.mvc

Fluent Assertions extensions for ASP.NET Core MVC

Extension methods to fluently assert the outcome of .NET tests

A very extensive set of extension methods that allow you to more naturally specify the expected outcome of a TDD or BDD-style unit tests. Works with .NET Standard 2.0 and higher, .NET Framework 4.7 and higher and .NET 6 and higher.

See https://www.fluentassertions.com for background information, usage documentation, an extensibility guide, support information and more tips & tricks.

Who created this?

Originally authored by Dennis Doomen with Jonas Nyrup as the productive side-kick. Notable contributions were provided by Artur Krajewski, Lukas Grützmacher and David Omid.

How do I build this?

Install Visual Studio 2022 17.8+ or JetBrains Rider 2021.3 as well as the Build Tools 2022 (including the Universal Windows Platform build tools). You will also need to have .NET Framework 4.7 SDK and .NET 8.0 SDK installed. Check global.json for the current minimum required version.

What are these Approval.Tests?

This is a special set of tests that use the Verify project to verify whether you've introduced any breaking changes in the public API of the library.

If you've verified the changes and decided they are valid, you can accept them using AcceptApiChanges.ps1 or AcceptApiChanges.sh. Alternatively, you can use the Verify Support plug-in to compare the changes and accept them right from inside Rider. See also the Contribution Guidelines.

Sponsors

     

With support from the following public sponsors

fluentassertions.aspnetcore.mvc's Issues

3.0.0 Planning

@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?

Better support for `ActionResult<T>`

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();

Upgrade to Fluent Assertions 5

New maintainers

@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?

Poor support for 'ActionResult<T>' type?

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?

Add shorthand support for typed ObjectResult assertions

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.

ActionResultExtensions are not working for Web API projects

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?

Nuget key expired

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

Potential `Should().BeRedirectAction(string action)` assertions

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?