为什么xUnit Assert.Equal函数期望实际值作为第二个参数[重复]答案

【问题标题】：Why does xUnit Assert.Equal function expect the actual value as second argument [duplicate]为什么xUnit Assert.Equal函数期望实际值作为第二个参数[重复]
【发布时间】：2020-11-16 17:57:04
【问题描述】：

XUnit 是一款出色的单元测试工具，我在每个 .NET 项目中都广泛使用它。

但是，我仍然不明白为什么在 Assert.Equal 函数中，“预期”值应该排在第一位。不这样做会在代码中触发警告。

实际上，说起来更自然：我想检查这辆车，它应该是红色，而不是相反的红色应该是那辆车的颜色。

此外，如果您将对象作为第一个参数传递，自动完成功能会为您提供实际参数的逻辑值：在下面的示例中，cache.APIConnectionStatus 是一个枚举，并且自动完成功能会触发一个下拉菜单写下断言时所有潜在的 Enum 值，这大大加快了编写过程。

有什么相反的理由吗？

我知道这是一个细节，有很多方法可以禁用警告/编写覆盖 Equal 方法的扩展，但最后每次我开始一个新项目时它看起来有点混乱和/或耗时。

【问题讨论】：

这可能是您应该直接向 XUnit 开发人员而不是 Stack Overflow 提出的问题。虽然我同意你对此事的看法。
@CaptainKenpachi 你是对的，但我不想在得到社区反馈之前在 GitHub 上提出问题 :)
我正在努力寻找一个不遵循此约定的单元测试框架（如果它使用Equal 样式断言）。除了“让我们遵循常规约定”之外，这可能不是 xUnit 开发人员做出的明确决定
其实有人问过why this convention existed in every test framework back in 2012
@XavierAM：请注意，Assert.IsTrue 像这样意味着如果断言失败，您获得的有用信息就会少得多。

标签： c# unit-testing xunit.net

【解决方案1】：

对于初学者来说，知道这两个值中的哪一个是预期值有助于生成错误消息：预期 x，实际值 y。所以这两个参数的顺序是固定的。

其次，为什么要把期望值放在首位？当然，这完全是任意的，但请考虑以下几行：

Assert.Equal(5, myTestObject.SomeProperty);
Assert.Equal(6, myTestObject.SomeOtherProperty);
Assert.Equal(2, myTestObject.SomePropertyObject.SomeProperty);
Assert.Equal(6, myTestObject.SomePropertyObject.SomeOtherProperty);

对我来说（但当然，这是个人的），它比替代方案更具可读性：

Assert.Equal(myTestObject.SomeProperty, 5);
Assert.Equal(myTestObject.SomeOtherProperty, 6);
Assert.Equal(myTestObject.SomePropertyObject.SomeProperty, 2);
Assert.Equal(myTestObject.SomePropertyObject.SomeOtherProperty, 6);

【讨论】：

我完全同意你的固定顺序，那不是我的意思。为了可读性，我完全不同意:-D。我更喜欢第二个选项（如果它不是 int，我会得到自动完成）但正如你所说，如果这个订单背后没有技术原因，那是完全任意的。