`ShouldBeEquivalentTo`、`ShouldAllBeEquivalentTo` 和 `BeEquivalentTo` 的使用

Question

我在单元测试中使用流畅的断言，但是 ShouldBeEquivalentTo、ShouldAllBeEquivalentTo 和 BeEquivalentTo 的使用尚不清楚。

例如；以下所有语句都通过，因此函数看起来是等效的。

List<string> a = new List<string>() { "james", "wood" };
List<string> b = new List<string>() { "james", "wood" };

a.ShouldBeEquivalentTo(b);
a.ShouldAllBeEquivalentTo(b);
a.Should().BeEquivalentTo(b);

为什么我应该使用一个而不是另一个？

Answer 1

作为概念，列表被视为一个单元。因此，从可读性的角度来看，选择一个选项，单个有效调用是 "a.ShouldBeEquivalentTo(b);".

关于其他的，他们是晦涩难懂的。

比较 2 个元素集合时应用复数形式 "ShouldAllBeEquivalentTo"。我认为，有人会争辩说我们正在将这些字符串组 (A) 与这些字符串组 (B) 进行比较。这里发生的事情是，字符串组在 List 数据结构类型下被收集为一个完整的单一概念。因此，我会说使用这个调用是错误的。

最后一种形式暗示了两件事。首先，对象 "a" 应该被转换成某种东西。 "Should" 这个名字没有传达任何信息。之后，比较结果是否等同于列表对象"b"。从逻辑上讲，应该比较 2 个相同类型的对象。不需要额外的转换。

阅读代码时，我更喜欢以下格式：

列表 "A" 等同于另一个列表 "B"。

List<string> a = new List<string>() { "james", "wood" };
List<string> b = new List<string>() { "james", "wood" };

//creating "IsEquivalentTo" method
bool listsAreEqual = a.IsEquivalentTo(b);

//creating "IsEqualTo" method
listsAreEqual = a.IsEqualTo(b);

//overloading operator ==
listsAreEqual = (a == b);

Answer 2

ShouldBeEquivalentTo和ShouldAllBeEquivalentTo是一样的，会做递归结构比较。但由于行为是高度可配置的，一些选项支持使用属性表达式来包含或排除某些成员。但是，表达式中的T在使用ShouldBeEquivalentTo时指的是根对象（List<string>）的类型，在使用ShouldAllBeEquivalentTo时指的是string。前者作用于整个对象而后者作用于IEnumerable<T>。

Should().BeEquivalentTo() 是一个更简单的实现，它将使用 Equals 进行 order-insensitive 比较。此方法将在下一次重大更改 (v5.x) 中删除。

`ShouldBeEquivalentTo`、`ShouldAllBeEquivalentTo` 和 `BeEquivalentTo` 的使用

Use of `ShouldBeEquivalentTo`, `ShouldAllBeEquivalentTo`, and `BeEquivalentTo`

c#

unit-testing

fluent-assertions