我发现自定义失败消息在相当有限的情况下非常有用。特别是当您断言对象的多个属性时,预期/实际值可能无法提供有关失败原因的最佳信息。考虑这样一个测试:
[Test]
public void CreateOrder_CreatesValidOrderForProvidedCustomer()
{
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)附近有差异。