support for NotContainInOrder

I would be great to get an generic collection assertion NotContainInOrder()

[SurajGupta]

I’m planning to write a blog post about my framework at some point, so the following thoughts are not complete nor organized, but after dropping that comment I do owe you some more details…

My frustrations started here: https://github.com/fluentassertions/fluentassertions/issues/357

Then it hit me that assertions as extensions methods on specific types, as an overarching framework concept, was too limiting versus an approach where you determine, in runtime, whether an assertion can be applied to a type. While the former approach gets you compile safety and bettter performance, you sacrifice grammar, which was a deal-breaker for me. For example, how to solve for the bug above? At some point you run out of C# trickery and you need to add another assertion like ContainsKeyInReadOnlyDictionary to work-around the shared interface issue.

Then that got me thinking - I was lukewarm on the assertion names in FA and it was appealing to name assertions as I wanted to write them (e.g. BeEqualTo instead of Be, BeSameRefererenceAs instead of BeSame). I also found myself having to refer back to the documentation a lot in the whole equals/equavalent/contains space in asserting against enumerables/lists/collections/dictionaries/etc. Actually, that took me on an unexpected detour to make it super easy to determine if two objects are equal, respecting the “contract” of the declared type (e.g. two ILists are equal if they are SequenceEqual, whereas two ICollections are more like set/unordered equality). I also really wanted to crack the nut on Dictionary equality and support types that were nested multiple levels (e.g. IReadOnlyDictionary<string, IList<…>>. This is not really a FA issue; .NET doesn’t help us here. But “equal” assertions are common and so the pain-points are felt when using FA (i.e. having to perform multiple lines of assertions to get at a single concept - are these two things equal using reasonable conventions?). Anyways, see https://github.com/OBeautifulCode/OBeautifulCode.Equality which also has no documentation, but has been a total pleasure to use in production code and backs any kind of equality/contains assertion in my library.

So then I got to thinking further - why do we use different frameworks for assertions in tests versus non-test methods? If x == null then throw ArgumentNullException is an assertion. There are frameworks out there for argument checking. What about “mid-method” (so after you have validated your arguments) assertions that might throw something like InvalidOperationException (e.g. if someValueReturnedFromDatabase == bad then throw InvalidOperationException). That’s just an assertion. Isn’t it so much better to have a single consistent framework/grammar for assertions across your code base? One issue is that you’d have a dependency on the assertion library EVERYWHERE. Any consumer of a library that made these assertions would have to take the dependency and thus the consumer’s consumers would have to take the dependency, and so on. My assertion library install itself as code (my colleagues and I call these “recipes”). So it’s compiled into the project and doesn’t appear to the external world as a required package install.

So now I live in the world where my argument checking looks like this: new { someArgument }.AsArg().Must().NotBeNullNorEmptyEnumerable(); (using an anonymous object you get the name of the argument for free in the resulting exception message, if an exception is thrown), but if you like you can also write someArgument.AsArg(nameof(someArgument)).Must().NotBeNullNorEmptyEnumerable();

otherwise, for InvalidOperationException, you might write this: valueFromDatabase.AsOp().Must().BeAlphanumeric(because: "usernames are limited to alpha-numeric characters")

and for tests: actual.AsTest().Must().BeEqualTo(expected);

these are just some examples, there’s more features.

Anyways, there’s a lot here and I really need to get this organized and presented in a more compelling way, because now that I live in this world I would never go back. The devs on my team feel the same way too =)

[dagilleland]

@krajek - Here’s a situation for needing a ContainButNotInOrder (which I do think is a better name). It’s for a deck of cards, to make sure it is randomized when reshuffled.

    public class A_Deck_Of_Cards_Must
    {
        DeckOfCards deck = DeckOfCards.OpenNewDeck();
        // ... other tests
        [Fact]
        public void Be_In_A_Different_Order_When_Reshuffled()
        {
            deck.Shuffle();
            var firstShuffle = new List<PlayingCard>( deck.Cards);
            deck.Shuffle();
            var reshuffled = deck.Cards;
            reshuffled.Should().ContainButNotInOrder(firstShuffle);
        }
    }

Granted, it’s not a “money-maker” example, but it’s one I’m facing right now in creating samples for teaching OOP with Unit Tests.

Other examples might be ensuring that two students get the same questions, but in a different order, or that the multiple choice answers are randomized.