Question

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

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

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

当上面的任何断言失败时，你会收到的信息将是：

预期：“非常重要的套餐”实际：“快速派遣”。

如果不查看单元测试（它使用的数据是精确的），很难告诉哪个属性。只需将属性名称添加为失败消息即可。

但是！

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

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

在没有明确解释原因的情况下单个测试失败，没有什么比这更令人烦恼了。

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

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

将报告为：

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

Answer 2

比较对于确定出错是非常有用的。 JUnit失败消息采用标准格式：

我期待this，但我得到this。

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

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

2 个答案: