如何在单元测试中测试两个对象的相等性？ [关闭]答案

【问题标题】：How to test equality of two objects in unit tests? [closed]如何在单元测试中测试两个对象的相等性？ [关闭]
【发布时间】：2016-07-14 19:42:16
【问题描述】：

我有一个项目，我在其中接收对象作为 DTO，并将它们转换为视图模型。为了进行这种转换，我决定制作自定义转换器，它会进行一些计算，以便从 DTO 属性转换为视图模型。在所有这些都准备好并且转换工作正常之后，我想在转换中添加一些单元测试以使其更稳定（我知道这不尊重 TDD，但这是我设法做到的）。

当我想通过测试来验证两个 View-Model 的相等性时，问题就来了

Assert.AreEqual(expected, actual);

因为没有一个 View-Model 定义 Equals 方法，并且它们永远不会与引用相等。我考虑并发现了一些方法来比较这些对象：

定义Equals 方法。但我不知道定义它是否是一个好习惯，仅用于测试目的。而且如果我定义的话，建议也定义GetHashCode方法，所以我觉得这个方案不是最好的。
我认为的另一种可能性是在测试项目中实现IEqualityComparer<T>，将比较逻辑与主转换项目隔离开来，甚至将其提取到第三个项目中，以便转换模块将来可以使用它如果有必要。这个实现看起来不错，但我不知道是否值得添加另一个包含许多类的项目，这也应该进行测试。
我在Stack Overflow question 上发现的第三种方法看起来很有趣，它是序列化两个对象并比较字符串。问题是我不知道这是否是一种编程的好习惯。

以下哪种方法是比较对象的最佳方法？我是否错过了一些可能更有效的方法？

注意：View-Model 是复杂的对象，我无法改变转换为其他技术的方式。

【问题讨论】：

似乎您已经概述了优缺点-除非它们是相同的类型，否则我不会相信序列化-具有相同属性的两种类型可能会以不同的方式进行序列化的原因有很多。
@DStanley 它们将始终是相同的类型，或者现在看起来是这样，尽管如果我正在创建一个具有泛型类型参数的方法，因为它是来自IEqualityComparer 的Equals，它接收两个对象而不是简单的比较，序列化它们并返回它们的字符串比较？这样够稳定吗？
@DStanley 我可以看到你已经投票结束这个问题，因为它太宽泛了，但我已经阅读了帮助中心什么是太宽泛，我认为这个问题不适合该部分的答案不需要写一本书的空洞内容，甚至不需要很长的答案。请考虑许多其他编程问题可以有多个答案，这很好，但这些都没有使它们太宽泛。谢谢！
实际上，我（和其他 4 人）投票决定将其关闭，因为您提出的所有解决方案在技术上都是可行的，因此“最佳”通常是意见问题。无论如何，您已经接受了“无害无犯”的答案。
@DStanley 我明白这一点，但任何其他建议都会受到欢迎，我认为让这个问题保持开放不会有什么害处。我仍然尊重你的决定！

【解决方案1】：

您的第二种方法比其他两种方法要好得多，因为它将特定于测试的代码与单元测试保持在一起，还因为它允许您更改对两个 View-Model 相等的含义的定义。

不过，将相等比较器移到一个单独的项目中几乎不值得：如果您打算共享相等比较逻辑，那么您不妨将其放入您的对象中。另一方面，如果它只是为测试而设计的，那么你应该把它和测试放在一起（即使用你的方法#1）。

基于序列化的方法太脆弱了，因为它依赖于一个不相关的特性（即序列化）来测试你实际测试的特性（即转换）。

【讨论】：

【解决方案2】：

我非常喜欢 Fluent Assertions 的 ShouldBeEquivalentTo 方法。

actual.ShouldBeEquivalentTo(expected);

默认情况下，这“正常工作”，假设您传入的两个对象在结构上是等效的，但您可以提供额外的参数来自定义您希望它如何进行比较。例如，如果您只想检查几部分对象的等价性，您可以说：

actual.ShouldBeEquivalentTo(new {
    expected.Name,
    expected.Description,
    expected.Code
}, options =>
    options.ExcludingMissingMembers);

【讨论】：