FluentAssertions ShouldBeEquivalentTo() versus Should().BeEq

Question

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

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

这个测试的变化失败了，错误是"预期项目[0]是InProcess，但发现Pending":

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

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

Answer 1

你说得对。应该(). beequivalentto()使用单个项目Equals()实现来验证等价性，并且从版本1开始就存在。在FA 2.0中引入的较新的ShouldBeEquivalentTo()会进行深入的结构比较，并报告任何差异。对于2.1，我将改变行为，使其更像默认的集合等效