3

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

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

4

2 回答 2

1

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

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

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

于 2012-06-29T13:56:45.973 回答
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"));
}

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

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

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

但！

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

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

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

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

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

将被报告为：

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

于 2012-06-29T14:13:29.477 回答