95. 为他人编写测试



为他人编写测试

        你已经在为自己的部分或者全部代码编写自动化测试了。恭喜你！你已经在编写代码之前编写测试了？更好！这样做已经让你成为先进软件工程实践的先行者了。但你写的是好的测试吗？如何分辨呢？一个简单的办法是问“我在为谁写测试？”如果答案是“为我自己，节省修正bug的力气和时间”，或者“为编译器，为了它们能够执行”，这样你很可能就不是在写最好的测试。你究竟应该为“谁”写测试呢？为了尝试理解你的代码的人。
        好的测试表现得像是被测试代码的文档一样，它们描述了代码如何工作，有这些使用场景：
        1. 描述必须满足的上下文、入口点或者前置条件；
        2. 解释说明软件如何被调用；
        3. 描述需要检查的期望结果或者后置条件。
        不同的使用场景可能有不同的版本。尝试理解你的代码的应该能够查看一些测试并在测试中带着问题比较这三个部分，能够看清楚软件行为不同的起因。每个测试都应该清楚地描述这三个部分的起因和影响关系。这暗示着测试中看不见的部分和能看见的部分同样重要。测试中太多的代码会让一些细枝末节的东西分散读者的注意力。当有需要时，就要将这些不重要的东西隐藏到有意义的调用背后——提取方法重构会很不错。确保你的测试有个含义清楚的名字，能够描述该测试的特定使用场景，于是测试的读者就不用对该测试进行逆向来理解它的使用场景是什么。测试类和方法的名字中应该至少包含开始点以及软件如何调用的信息，这就能够通过快速的方法名称描述来得到覆盖率。只要不会让名字太长、太难看的话，将测试结果也包含在方法名中也会很有帮助。
         测试自己的测试也是一个好主意。你可以检查你认为它们检测到的错误，通过将这些错误插入产品代码（当然是会被丢弃的你自己的私人版本），确保它们以有帮助的方式报告错误。你也应该检查你的测试对一个尝试理解你的代码的人是否能清楚地表达它的意思，最好的办法是让不熟悉你的代码的人阅读你的测试并告诉你他们学到了什么。仔细倾听他们说了什么，如果他们没有清楚地理解某个东西，很可能不是因为他们不够聪明，而是你自己没写清楚。（开始吧，并调整你的角色，阅读他们的测试！）

原文：Write Tests for People by Gerard Meszaros