如何编写优秀的单元测试

按照这三条规则，你就能节省时间，并避免争论。

何为优良的单元测试？这是实效程序员(Pragmatic Programmer)的邮件列表最近提出的一个问题。读者David Bock讲述了一个与测试有关的故事，这个测试在深夜编码时突然开始出错。

“我开始检查最近所做的修改，不知道为什么这些修改会使测试中断。经过几次眼皮发胀的检验后，测试又不可思议地再次开始运行起来。我看了一下时钟：午夜12：03。

“我盯着测试：它正在用测试运行的日期/时间测试一个方法（基本上，就是新Date();）。我看着这个方法：它因为一个错误而中断，如果你在下午11：00到11：59：59之间询问它，方法返回今天正午。”

David继续指出这个故事的三个寓意——编写测试的指导方针。其他开发者也补充了他们的一些观点，但大多数都与这三个主题有关。

• 使单元测试在各个方面都可以反复验证。例如，一个使用当前日期/时间的测试在每次执行时用一个随机值进行测试。如果一个测试不能像预计的那样和你的其它单元测试一样同时运行，就表明应该消除某种环境耦合。
• 测试边界条件。例如，测试午夜、正午前后的分钟和秒钟，以及闰日前一天等。在我学习单元测试之前，我经常对代码进行测试，看它能否在我所能想到的各种情况下运行，只要能够运行就可以。但现在我可以将它应用到单元测试中，观察它的运作模式，并发现我没有测试的漏洞。更不用提每次修改代码后单元测试都能重复运行。
• 总是保持100%的测试通过率。有两个主要原因促使你逃避这个任务。原因之一在于测试用的时间可能过长。“如果运行所有单元测试要用的时间超过一分钟，”另一位读者补充说：“你就会失去耐心，不愿意运行它们。”
  
  一些人提到的“破窗综合症”是通过率不到100%的第二个原因。David写道：“我们有大约15个测试会失败…最初可能是‘最多一星期’，然后变成两个星期，接着再往后拖一段时间。人们开始习惯看到15个左右的测试失败。因此当它们上升到17并下降到14时，没有人会真正注意到这一情况。”

我们很容易无意识地陷入这种境地。在David的例子中，连续的修改本可以早些发现测试失败，但却被噪音掩盖。因此如果你发现了一个破窗，嗯…测试，你应该停止现在的工作，立即修改这个错误。如果无法停止手头的工作，那么把错误标注出来，稍后再回过头来修改。使问题更加突出。

当然，编写优秀测试的建议并非只有这三条，但遵照这些建议是一个好的开始。也许可以减少你熬夜的次数！

责任编辑：张琎

查看本文国际来源