FluentAssertions ShouldBeEquivalentTo() versus Should().BeEquivalentTo()

Question

I have a test that verifies the collection output of a method. This variation of the test passes:

    [TestMethod, TestCategory("BVT")]
    public void TheStatusesAreReturned()
    {
        var expectedUnprocessedStatuses = new List<FileUploadStatus>
            {
                FileUploadStatus.InProcess,
                FileUploadStatus.Pending,
            };

        Sut.GetUnprocessedStatuses()
            .Should()
            .BeEquivalentTo(expectedUnprocessedStatuses);
    }

This variation of the test fails, with the error "Expected item[0] to be InProcess, but found Pending":

    [TestMethod, TestCategory("BVT")]
    public void TheStatusesAreReturned2()
    {
        var expectedUnprocessedStatuses = new List<FileUploadStatus>
            {
                FileUploadStatus.InProcess,
                FileUploadStatus.Pending,
            };

        Sut.GetUnprocessedStatuses()
            .ShouldBeEquivalentTo(expectedUnprocessedStatuses);
    }

Clearly, ShouldBeEquivalentTo cares about collection item order, whereas BeEquivalentTo does not. Why is the notion of equivalency different between the 2 methods?

Filterable

Answer 1

You're correct. Should().BeEquivalentTo() is using the individual items Equals() implementation to verify equivalence and has been around since version 1. The newer ShouldBeEquivalentTo() introduced in FA 2.0 is doing an in-depth structural comparison and also reporting on any differences. For 2.1 I'm going to change the behavior to be more like the collection equivalency by default

Canst

Ok, I look forward to the update. I use Should().BeEquivalentTo() quite a bit! – Filterable

This is an old post, but ShouldBeEquivalentTo will ignore the order of items in collection since v2.1. – Canst