单元测试失败消息的推荐标准？答案

【问题标题】：Recommended standards for unit test failure messages?单元测试失败消息的推荐标准？
【发布时间】：2012-06-29 13:08:29
【问题描述】：

这是单元测试的一个相当小的方面，但我很好奇（通常是可选的）失败消息，您可以定义它以在测试执行期间测试断言失败的情况下显示。 对于何时使用此类消息以及在其中包含哪些信息是否有推荐做法？

例如，我猜不是每个断言都需要定义失败消息，也就是说，当测试的预期结果非常清楚时。但是在某些情况下，您可能希望在执行单个操作后测试对象的几个方面，这意味着您可能在一个测试方法中列出了几个断言。该场景中的每个断言是否应该有一个描述性的失败消息，以便很容易看出为什么测试方法可能在给定点失败？

【问题讨论】：

也许不是您的问题的答案，更多的是提示，但是如果您使用 Hamcrest 匹配器而不是老式的断言，则默认情况下消息会更好，并且很少需要提供自定义消息.编辑：以为我在 Java 标记中，我的评论是 Java 特定的......
没问题，谢谢指点！我主要在 C# 中工作，但我在其他语言中也有同样的问题，所以我让它与语言无关。

标签： unit-testing

【解决方案1】：

我发现自定义失败消息在相当有限的情况下有用。特别是，当您断言对象的多个属性时，预期/实际值可能无法提供有关失败原因（和原因）的最佳信息。考虑一个测试，例如：

[Test]
public void CreateOrder_CreatesValidOrderForProvidedCustomer()
{
    // Assume we arranged test here

    var order = orderFactory.Create(customer);

    Assert.That(order.Type, Is.EqualTo("Immediate Dispatch"));
    Assert.That(order.Details, Is.EqualTo("Very Important Package"));
    Assert.That(order.CustomerNote, Is.EqualTo("Send fast or I tell mom"));
}

当上述任何断言失败时，您将收到的消息大致如下：

预期：“非常重要的包裹”实际：“快速发送”。

如果不查看单元测试（它使用的数据是精确的），很难判断 是哪个 属性导致了这种情况。在这里只需添加属性名称作为失败消息即可。

但是！

这只是极端情况，当多个断言的属性可能难以区分内容方面时。通常，您不应该遇到这样的问题（请注意，我们通过提供 one 字长期望消息来解决它）。如果您觉得需要使用长而描述性的期望信息，这可能表明您的测试过于复杂。您可以考虑将其拆分为几个测试，或者甚至重新设计测试类。

最重要的是，我建议看看像FluentAssertions 这样的项目。他们做对了：

没有什么比没有清楚解释原因而失败的单元测试更烦人的了。

并以非常简洁的语法和简洁的错误报告解决了这个问题：

"1234567890".Should().Be("0987654321");

将报告为：

预期的字符串是
“0987654321”，但是
“1234567890”在“123”（索引 0）附近有所不同。

【讨论】：

【解决方案2】：

比较对于确定问题所在非常有用。 JUnit 失败消息采用标准格式：

我期待this，但我得到了this。

如果你能显示差异标记就更好了。

【讨论】：