单元测试和测试驱动开发

[Guo-Zhang]

单元测试不是“测试”，而是代码的一部分，比较规范的实践是谁开发谁写单元测试；只有集成测试以上的测试才值得或者需要分出测试工程师来负责。在项目早期架构不稳定，或者大版本更新重构的时候，单元测试面临反复修改是正常的，我们恰恰是需要这种变动来反映代码单元的API变动，从而确保架构变动的影响对开发者透明（即可以通过观测单元测试的变动观测到，而不是凭着印象）。这种透明可以帮助开发者很好地评估重构是不是真正解决了原本的实现里的缺陷的同时、没有丢失掉原本的特性或者优点。当重构发生地更加审慎的时候，变动的发生就会更加平滑；同时也会给开发者潜移默化的影响，由于重构有成本，在一开始设计API的时候就会更加审慎，从而提高工程质量。

在更加正式的“测试驱动开发”中，一般流程是写单元测试、实现、重构，也正是在上述的原则下，提供了一个更加规范的实践准则。第一步设计单元测试实际上就是设计API的入参和出参；而基于单元测试的重构会更加地敏捷可靠，你不用提心吊胆地想着我的变动对全局的影响，而是可以专注于当前的这一点。这样的实践会让代码质量有比较明显的提升。

简单概括，因为软件开发太过自由，因此软件工程采用适当的方法加以审慎的约束。

具体到技术管理者，培养技术团队写单元测试的习惯是非常重要且困难的，一定会遇到很大的阻力，但是一定会获得很好的回报。

[Guo-Zhang]

两个建议:

1. 每个新增代码都配套单元测试；
2. 单元测试覆盖完善是保证重构质量的重要前提。