FluentAssertions：ShouldBeEquivalentTo vs Should().Be() vs Should().BeEquivalentTo()？

【问题标题】：FluentAssertions: ShouldBeEquivalentTo vs Should().Be() vs Should().BeEquivalentTo()?FluentAssertions：ShouldBeEquivalentTo vs Should().Be() vs Should().BeEquivalentTo()？
【发布时间】：2014-11-13 13:20:05
【问题描述】：

谁能总结一下它们之间的区别和使用范围？

我读过 SO 文章，

ShouldBeEquivalientTo()：ShouldBeEquivalentTo() 旨在用于比较复杂的对象图，而不是 .NET 框架的原始类型部分。
Should().BeEquivalentTo()：单个项目 Equals() 实施以验证等效性，并且自版本 1 以来一直存在。FA 2.0 中引入的较新的 ShouldBeEquivalenTo() 正在进行深入的结构比较，并报告任何差异。
Should().Be()：找不到。

以我的拙见，如果Should().BeEquivalentTo() 进行深入比较，ShouldBeEquivalientTo() 和 Should().BeEquivalentTo() 的工作原理相似。

【问题讨论】：

对于字符串比较ShouldBeEquivalentTo表示不区分大小写匹配

标签： c# comparison fluent-assertions

【解决方案1】：

我同意这令人困惑。 Should().BeEquivalentTo() 实际上应该称为 Should().EqualInAnyOrder() 或类似的名称。正如您所说，它使用所涉及对象的Equals 实现来查看expected 集合中的所有对象是否都出现在actual 集合中，无论顺序如何。我需要为下一个主要版本修复它。

【讨论】：

谢谢。 Should().Be() 怎么样？它的工作原理是否与其中之一相似或完全等效？
只有Should().Equal() 与Should().BeEquivalentTo() 功能相同，但需要严格排序。这就是为什么我建议将 BeEquivalentTo 重命名为 EqualInAnyOrder。
这已在 5.0 中得到解决。在continuousimprover.com/2018/02/… 阅读所有相关信息