如何编写好的单元测试消息答案

【问题标题】：How to write a good unit test message如何编写好的单元测试消息
【发布时间】：2011-12-20 03:20:19
【问题描述】：

我最近开始在我的项目中编写单元测试，我注意到所有的断言语句都有一个消息参数。

什么是单元测试的好消息？

$cache->set('foo', 3);
$this->assertEquals($cache->get('foo'), 3, 'what should i say?');

谢谢！

【问题讨论】：

在这种特殊情况下：“缓存中 foo 的值是 3”（尽管如果对 why 有更多了解，您希望它是 3，这将是答案）。一般来说，做一个积极的陈述，说明你正在测试的情况是保持不变。（另见stackoverflow.com/questions/1074928/…）

标签： unit-testing testing

【解决方案1】：

陈述被测试的事实。

考虑：

$this->assertEquals($person->age, 21, "Age is 21")

对比：

$this->assertEquals($person->age, 21, "Age of person born on 1990-12-20");

一个好的单元测试消息应该可以帮助您快速猜出错误在哪里。一个坏的会让你花更多的时间去打猎。

【讨论】：

@holigeek 那么哪个更好呢？ ``` $this->assertEquals($person->age, 21, "Age is 21") ``` 这个消息只是在重复断言语句。基本上，没有添加任何价值

【解决方案2】：

我通常会保持它们简洁明了 - 正是正在测试的内容。该信息不必解释所有可能出错的事情的故事，它只需要为读者指出正确的初始方向。测试应该足够清晰，他们可以从那里弄清楚。

一般来说，我写我的信息是为了让不熟悉测试的人至少有一点上下文，而更了解测试的人可能会确切地知道哪里出了问题（或者至少在测试中的哪个位置）出了点问题）。

在上面的示例中，我会说类似“'foo' 的缓存”，这样消息就会返回“'foo' 的缓存预期为 3，但为 67”。对于熟悉测试的人来说，这将比“预期为 3，但在测试 abc 的第 123 行中为 67”有用得多。

（我主要是一名 Java 开发人员，所以我说的好像这是 JUnit；我假设 phpunit 或任何它被称为的工作方式大致相同。）

【讨论】：

【解决方案3】：

This article 很好地跳过了 message 参数。总结：

以描述性/有用的测试方法名称为目标（这通常会消除对消息的需求）
目标是每个测试有一个断言（以便测试方法名称可以描述该单一目的）
包含一条消息作为最后的手段（例如，如果无法遵守上述规定）

旁注：我发现使用 DataRows 之类的功能时消息很好。该消息有助于区分哪个 DataRow 可能失败。 C#/VS 测试示例：

[TestMethod]
[DataRow(<some arguments>, <message1>)]
[DataRow(<some arguments>, <message2>)]
[DataRow(<some arguments>, <message3>)]
public void MyTest(<some params>, string message)
{
    ...
}

【讨论】：