Google软件工程过程之高效可维护的单元测试

对测试进行分类的两个主要方面是粒度和范围。粒度是指测试消耗的资源和允许他做的事情，而范围是指测试打算验证多少代码。单元测试指范围相对狭窄的测试，例如单个类或方法的测试。单元测试通常粒度较小，但也有例外。

测试最重要的目的是提高工程师的工作效率。单元测试是优化生产力的一种极好的方法:

单元测试的粒度往往很小。小型测试是快速和确定的，允许开发人员在流程中频繁运行它们并获得即时反馈。

在编写生产代码的同时编写对应的单元测试代码，往往更容易些，也会让工程师将测试的重点放在正在处理的代码上，而无需设置和理解更大的系统。

编写单元测试又快又容易，能促进达成较高的测试覆盖率水平，高测试覆盖率使工程师能自信地做出变更，并确保不会破坏任何东西。

单元测试在运行失败时，更容易被理解是哪里出了错。

单元测试可作为文档和示例，向工程师展示他正在测试的系统，以及该系统的预期工作方式。

测试需要有可维护性。可维护的测试是指可工作的测试，在编写它们之后，工程师不需要再考虑它们，直至它们运行失败。这些失败表明出现了真正的有明确原因的缺陷。

脆弱的测试是指在对生产代码进行不相关的变更，而又不会引入真正缺陷时，但测试却失败了。工程师必须诊断和修复这类测试，将此作为工作的一部分。脆弱测试会给任何规模的代码库带来痛苦。

努力做到不更改测试。对于重构，系统的行为不发生变化。对于新特性，系统的已有行为不受影响。修复缺陷会增加缺少的用例，但不应当改变已有用例。只有当系统行为改变时，才需要改变用例。

编写清晰的测试。为了使测试套件随着时间的推移能够扩展并且有用，该套件中每个单独的测试都尽可能清晰是很重要的。

帮助测试实现清晰性的两个高层属性是完整性和简洁性。一个测试的主体应该包含理解它所需的所有信息，而不包含任何无关的或分散注意力的信息。不要把逻辑放进测试。

每个测试只需处理一组特定的输入。测试代码本身不需要还要被测试。

编写清晰的失败信息。清晰表明期望的结果，实际的结果，任何相关的参数。

作为软件工程师，我们必须确保我们的系统面对未预料到的变化时能长期工作。单元测试是强大的工具，但需要保持可维护性。

单元测试原则:

努力做到不更改测试，通过公共API进行测试，测试状态而不是交互，使你的测试完整而简洁，测试行为而不是方法，强调行为的结构化测试，以行为给测试命名不要把逻辑放进测试，编写清晰的失败测试，为了简单清晰测试代码可以重复。