Description

First off: thanks for the awesome library! We've been using it for a few years now and it's been a huge boon to our tests :)

This is kind of a https://xkcd.com/1172/ situation, but I thought it'd be at least worth writing down to see what other people think.

Previously, using foo.Should().BeEmpty() on a non-empty collection would produce a result like "expected foo to be empty, but was {1, 2, 3}". Now it produces an error like "expected foo to be empty, but found at least one item {1}".

This is annoying in the case where the test needs to be re-run multiple times to discover more unexpected items in the collection, especially if the test is slow to run or can only be run on the CI server. An example in our case is checking for dlls that are part of the installed product which aren't authenticode-signed.

Reproduction Steps

[Test]
public async Task Check_things_are_valid()
{
    var things = new List<string> { "fine", "PROBLEM", "other_fine", "OTHER_PROBLEM" };

    var problems = new List<string>();
    foreach (var thing in things)
    {
        if (!await SomeLongWindedProcessToCheckIfThingIsValid(thing))
        {
            problems.Add(thing);
        }
    }
    problems.Should().BeEmpty();
}

private Task<bool> SomeLongWindedProcessToCheckIfThingIsValid(string thing) =>
    Task.FromResult(thing == thing.ToLowerInvariant());

Expected behavior

The error message from the test should list all of the problems so they can be fixed in one go.

As a potential compromise in the case of infinite collections, it could maybe list up to some max number of items?

Actual behavior

The error message from the test only lists one problem at a time, meaning we have to fix one at a time, push and wait for a CI build to see if there's another problem or not

Regression?

This appears to have been an intentional change in #2530

Known Workarounds

problems.Should().Equal([]); prints out all of the problems (but looks wrong: someone will come along and say "why don't you just use BeEmpty?")

Configuration

using FluentAssertions 6.12.1 and .NET 8.0.403

Other information

No response

Are you willing to help with a pull-request?

Maybe? I don't really know the code that well but can try if we agree on a change