测试驱动开发——让你的代码更简洁

盖房子时，工人师傅砌墙会先用桩子拉上吊线，以吊线为基准，以使砖能够垒的笔直。而测试驱动开发也是如此，先写一个测试，然后研发过程以此为基准，只编写能通过这个测试的功能代码。

顺序颠倒下，先垒砖，再拉吊线看墙面是否笔直，不直的话进行校正。这个过程就像传统的软件开发流程，先写功能代码，然后进行测试，有错误再一点点修改，因此，会严重影响研发效率。

测试驱动开发的目标

代码整洁可用，是测试驱动开发所追求的目标。但有很多因素会妨碍我们得到整洁的代码，甚至是可用的代码。

如何实现测试驱动开发？

1.  只有自动测试失败时，我们才重写代码；

2.  消除重复设计，优化设计结构

这两条规则实际上也蕴含了开发过程中所经历的阶段。 测试驱动开发的整个流程正是将目标拆分，先达到“可用”目标，再追求“简洁”目标。

测试驱动开发的流程

1.  首先思考并编写用于定义产品代码 行为的测试

2.  运行测试，发现新增的测试不能通过

3.  编写适当够用的代码

4.  运行测试，直至测试通过

5.  重构代码，以消除重复设计，优化设计结构

6.  运行测试，验证重构是否引入新的错误，直至测试通过且无需再重构

7.  最后重复上述步骤

测试驱动开发其实是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。

测试驱动开发，要求测试可以完全自动化运行，在对代码进行重构前后，必须运行测试。这有助于编写简洁可用和高质量的代码，能快速响应变化，并加速开发过程。

测试驱动开发的三定律

定律一：在编写不能通过的单元测试前，不可编写生产代码。

测试驱动开发主张“测试先行”，这意味着我们必须先写单元测试，并且该单元测试必然失败，才能编写生产代码。

定律二：只允许编写刚好能够导致失败的单元测试，编译失败也属于一种失败。

测试驱动开发鼓励“简单设计”，以很小的增量进行开发，遇到设计问题时能够及时解决，不要期望一个测试能实现多个功能。

定律三：只允许编写刚好能够使得失败的单元测试通过的生产代码。

简洁，尽最大可能减少不必要的工作，也是敏捷基本原则之一。要避免盲目编写将来有可能需要的代码。

遵循了测试驱动开发的这三条定律，那所有代码都是可测试的了。“可测试”的另一个词是“解耦”，为了单独测试模块，必须将其分离，所以测试驱动开发强迫分离模块，迫使大家创建更好、更少耦合的设计。

Kent  Beck最早在其极限编程方法论中，向大家推荐“测试驱动”这一最佳实践。极限编程中所有实践方法并不是独立的，而是相辅相成的。欢迎大家关注极限编程系列往期视频，了解更多极限编程实践方法。