Today I created two extension methods for the GenericCollectionsAssertions class to check that the collection is in order or is not in order.  I'm posting them here for anyone else to use or (if they are worthy) for them to be incorporated into the FluentAssertions library:

internal static AndConstraint<GenericCollectionAssertions<T>> BeInOrder<T>(
    this GenericCollectionAssertions<T> gca)
{
    var orderedItems = gca.Subject.OrderBy(item => item);
    return gca.Subject.Should().ContainInOrder(orderedItems);
}

internal static AndConstraint<GenericCollectionAssertions<T>> NotBeInOrder<T>(
    this GenericCollectionAssertions<T> gca)
{
    var orderedItems = gca.Subject.OrderBy(item => item).ToList();
    var items = gca.Subject.ToList();

    for (var i = 0; i < items.Count()-1; i++)
        if (!orderedItems[i].Equals(items[i]))
            return new AndConstraint>(gca);

    Execute.Verification
        .FailWith("Expected collection {0} to not be in order.", gca.Subject);

    return new AndConstraint>(gca);
}

Tony

Nice. I think we'll incorporate this into the trunk.

Added as a change request for release 2.0.0.

I will create two assertion methods:

Should().BeInAscendingOrder()
Should().BeInDescendingOrder()

I also want to add their counter parts Should().NotBeInAscendingOrder() and Should().NotBeInDescendingOrder(), but I wonder what the use would be to do such assertion. Can you give me an example of when you would like to check if a collection is not in order?

We were recently relying on an API for a vendor application and one of the functions was supposed to return a collection in DateTime order.  I was writing some boundary tests to ensure the API behaved as expected and wanted to ensure the data was in fact ordered chronologically but I had to ensure the results weren't chronological by accident.  If the rows were added to the database in chronological order then the data would be in both ID and DateTime order.  Therefore, if the results were being returned in ID order the test would still have passed.  I wanted to assert that the ID's were OUT of order but the DateTime values were IN order.  Part of the assertions for the test were to ensure the test data had been setup correctly as this was outside of our control in this instance.

Granted, this is an unusual case and under normal circumstances you would could argue that we shouldn't be testing something which was outside our control in this way.  Ordinarily data would be manufactured to suit the needs of the test and dependencies mocked, etc.  However, we felt it valuable to ensure the actual behaviour of the vendors API matched our assumptions as it was critical to the business logic of the solution.

Another example I can think of is if you wanted to assert that a list had been shuffled perhaps?  A shuffled playlist for instance.

Tony

Just a note that these methods are now part of FA 2.0 Beta. Read all about it here:

http://www.dennisdoomen.net/2012/08/breaking-with-past-orfluent-assertions.html

That's great. I look forward to the release.

Any ideas how to combine these when dealing with nested collections?

Meaning, say I wanna do this:

actual.ShouldHave().AllProperties().IncludingNestedObjects(CyclicReferenceHandling.Ignore).EqualTo(expected);

but in case there are nested collection involved, call 'NotBeInOrder' instead of the current 'Equal' behavior.

(I'm fetching data from a database and can't rely on order)

Thanks!

In the 1.7.x version you can't change the way collections are compared. But in the 2.0 beta you can. Read this blog post to learn more about that:

http://www.dennisdoomen.net/2012/09/asserting-object-graph-equivalence.html