测试类转换方法的正确方法答案

【问题标题】：Right approach to test convert-like methods测试类转换方法的正确方法
【发布时间】：2011-08-09 12:58:16
【问题描述】：

假设我有很多这样的类 (Foo1, Foo2 ..)

class Foo 
{
    public int F{get; set;}

    public Bar ConvertToBar ()
    {
        return new Bar(){ B = this.F*10 };
    }
}

它们的共同点是 ConvertToBar() 方法。

我有两种方法对该方法进行单元测试：

调用 convert 到 ConvertToBar () 并检查它的所有属性（我必须在每个 Foo 类的所有测试中都这样做）

Bar bar = foo.ConvertToBar(); Assert.AreEqual (expectedValue, bar.Property); ...
编写比较两个 Bar 实例的辅助方法，然后像这样使用它：

Bar 预期 Bar = 新 Bar () Assert.True( barCompareMethod (expectedBar, foo.ConvertToBar ());

为此方法编写单元测试的最佳方式是什么？

【问题讨论】：

【解决方案1】：

Bar 本身是 IEquatable<Bar> 有意义吗？如果是这样，我会在您的生产代码中实现它，而不是使用辅助方法。然后你就可以使用Assert.AreEqual(expectedBar, actualBar)。

【讨论】：

而且，如果在测试转换的所有类主题中实现IEquatable<T> 的努力是否有意义，您怎么看？这将是一场噩梦！
+1 我自己总是选择 IEquatable，但请参阅我的回答，了解如何处理不合适或不可行的情况。
@Orsol：那么实现IEqualityComparer<Bar> 是有意义的——或者可能只是创建一个辅助方法，正如你所建议的那样。事实上，辅助方法可以是一个 AssertBarEquals 方法，它可以指示它们的不同之处。
@Matías：嗯，转换的目标在这里很重要……而且 OP 说他只有一种目标类型。我发现转换的目标通常是无论如何都有相等性有用的类型。
@Jon Skeet 我同意，这只是对作者的建议，因为这可能是一个有限的例子，如果采用 'IEquatable' 方法，他需要考虑会发生什么:)

【解决方案2】：

正如 Jon Skeet 所建议的，只要您了解如何避开 Equality Pollution，在 Bar 上实现自定义相等是一个好主意。

对于语义比较，您可以使用AutoFixture 的 SemanticComparison 库，它可以让您编写如下断言：

var expected = bar1.AsSource().OfLikeness<Bar>();
expected.ShouldEqual(bar2);

ShouldEqual 方法是一个自定义断言，它将比较每个属性（按名称匹配），并且只有在所有属性相等时才会成功；否则会抛出描述性异常。

【讨论】：

【解决方案3】：

我不确定有没有最好的方法。

在我看来，第一个更具可读性。您可能想尝试NUnit's property constaints

Assert.That(someObject, Has.Property("Version").EqualTo("2.0"));
第二个需要做更多的工作，因为您必须在 Bar 类中定义 Equals（如果您没有源代码编辑权限，可能会出现问题）。但如果需要对大量属性进行断言，这将是更可取的。

【讨论】：

我个人发现，对于执行简单的相等测试，属性约束比简单的 Assert.AreEqual 测试可读性差得多。我知道有些人喜欢它，但我自己不是粉丝......
@Jon - 真的。我正在回答问题中的示例。如果一个对象有 n 个属性，其中只有 1 或 2 个与当前测试的上下文相关，我更喜欢约束或匹配器，因为它们倾向于突出更改。如果大多数属性是相关的，那么我同意平等方法方法获胜..我现在正在尝试使用 Hamcrest 匹配器..所以可能会受到影响:)
我的意思是一个简单的Assert.AreEqual("2.0", someObject.Version)，而不是使用Has.Property 语法。我也从来不是 Hamcrest 的粉丝 ;)
@Jon - 引用荷马辛普森的话“DOH！” :) 我只是立即对 Has.Property 失去了信心。即使AssertThat(someObject.Version, Equals("2.0")) 更好。