这是《落叶》文集里第 336 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【提问】
为什么一定要做单元测试？
【旧识】
很久之前，我在学习《Head First Java》那本书的时候，应该是我第一次接触单元测试。书中在教到写一个类的时候，都是按照下面的顺序：
- 伪代码（一种算法描述语言，让你专注于逻辑，而不需要考虑程序语言的语法）
- 测试代码（测试功能程序的代码）
- 功能代码（实现功能需求的代码）
开始实践时还不太理解为什么按照这个顺序去做，觉得都还没有完成可以测试的代码，就去写测试代码，意义在哪？后来看了书中的解释，并自己实践了一段时间，觉得还是有一定好处的。在开始写真实类的代码之前，通过思考和编写测试代码，可以更好的了解要实现的这个类应该要做的事情。
这应该就是我最初对单元测试的理解：通过写测试代码去测试功能代码。
【新知】
在之后这些年的项目过程中，听到开发抱怨最多的就是：时间太紧了，哪有时间做单元测试？等都集成好之后，提交给测试先，发现问题再改吧。先不说那些通过 KPI 指标来约束开发必须做单元测试的，因为那种只是因为公司要求做单元测试才去做的，其实并不清楚为什么要做。
我们就从产品研发本身来看看为什么一定要做单元测试吧：
- 质量保证工作的前置，问题修复的成本肯定是越早越低。
拿制造业举例：检测工作都是从最小的零部件开始的，当问题被发现在最小零部件的检测时，修复起来很容易，但如果最小零部件被组装成了成品之后，再发现问题，修复起来就会复杂很多，成本也就增加了很多。
- 产品发布的敏捷化要求。
（1）互联网产品越来越多地偏向敏捷化，在软件编码过程中，原来独立的由单元模块组装成完整的系统的过程已经不太适用了，这个过程已经慢慢地变为一个持续性地过程，也就是持续集成。持续集成的第一步就是自动构建，想要保证自动构建的成功，就需要有合格的单元代码，想要单元代码合格，就需要单元测试。所以，单元测试是后续系统持续集成的前提和基础，是持续集成合格输入的保障。
（2）测试驱动开发（Test-Driven Development，TDD）是敏捷开发中的核心实践。而这里的测试，指的也就是单元测试。
- 根据被测对象的功能要求编写一段最简单的、必然会执行失败的单元测试代码。
- 开发最简单的、可以让单元测试执行成功的功能代码。
- 重构代码，让代码满足功能需求。
- 修改单元测试代码，增加新的用例，让执行变为失败。
- 修改和重构代码，让执行可以成功。
TDD 就是这么一个测试先行和持续重构的迭代过程，从而保证单元测试的100%代码覆盖。
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
