单元测试失败消息的推荐标准是什么？

Question

这是单元测试中相对较小的一个方面，但我对（通常是可选的）失败信息很感兴趣，这些信息可以在测试执行期间定义，以显示断言测试失败的情况。关于何时使用这些消息以及包含哪些信息，是否有建议的做法呢？

例如，我猜测并不是每个断言都需要定义失败消息，特别是当测试预期结果非常明确时。但在某些情况下，您可能希望在执行单个操作后测试对象的几个方面，这意味着您可能会在一个测试方法中列出几个断言。在这种情况下，是否应该为该场景中的每个断言都设置描述性的失败消息，以便轻松查看测试方法在某一点上为什么可能失败？

- Derek

---

也许不是你问题的答案，更像是一个提示，但如果你使用 Hamcrest 匹配器而不是老式的断言，消息默认会更好，并且很少需要提供自定义消息。编辑：我以为我在 Java 标签中，我的评论非常针对 Java... - K Erlandsson

没问题，感谢你的指引！我主要用C#开发，但我在其他编程语言中也遇到过同样的问题，所以我保持了语言无关性。 - Derek

Answer 1

比较非常有用，可以确定出错的原因。JUnit失败消息采用标准格式：

我期望得到this，但实际上得到了this。

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

- Garrett Hall

Answer 2

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

[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"));
}

当上述任何一项断言失败时，您将收到以下类似的消息：

期望值："非常重要的包裹" 实际值："快速派送"。

如果没有查看单元测试（确切地说是使用的数据），很难确定是哪个属性导致了这种情况。在失败消息中添加属性名称可以帮助解决这个问题。

但是！

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

除此之外，我建议您查看像FluentAssertions这样的项目。他们做得很好：

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

并通过非常干净的语法和整洁的错误报告解决了这个问题：

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

将被报告为：

预期字符串应为
"0987654321"，但
"1234567890" 在“123”（索引0）附近有差异。

- k.m