FluentAssertions ShouldBeEquivalentTo() 与 Should().BeEquivalentTo()答案

【问题标题】：FluentAssertions ShouldBeEquivalentTo() versus Should().BeEquivalentTo()FluentAssertions ShouldBeEquivalentTo() 与 Should().BeEquivalentTo()
【发布时间】：2013-04-15 11:54:03
【问题描述】：

我有一个验证方法的集合输出的测试。这个变体测试通过了：

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

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

此测试变体失败，出现错误“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);
    }

显然，ShouldBeEquivalentTo 关心收集项目的顺序，而BeEquivalentTo 不关心。为什么这两种方法的等效概念不同？

【问题讨论】：

标签： unit-testing fluent-assertions

【解决方案1】：

你是对的。 Should().BeEquivalentTo() 正在使用单个项目 Equals() 实现来验证等效性，并且自版本 1 以来一直存在。FA 2.0 中引入的较新的 ShouldBeEquivalentTo() 正在进行深入的结构比较，并报告任何差异.对于 2.1，我将默认情况下将行为更改为更像集合等效

【讨论】：

好的，期待更新。我经常使用 Should().BeEquivalentTo()！
这是一个旧帖子，但ShouldBeEquivalentTo 将忽略自 v2.1 以来集合中的项目顺序。