测试驱动开发

最近看了几篇关于测试驱动开发的文章，简单总结下：

TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析、设计、质量控制量化的过程。说白了就是在开发功能代码之前，先编写测试代码，然后只编写使测试代码通过的功能代码，从而以测试来驱动整个开发过程的进行。

1.在开始工作前，由业务分析人员，测试人员，开发人员进行一次讨论，就验收条件达成一致并形成记录,这样可以避免测试和开发人员理解不一致现象出现。

2.根据某一个具体的需求列一个TODO-list出来，以提醒我们需要做哪些事情，它将使我们始终保持注意力集中，同事它也可以告诉我们什么时候可以完工。如果我们想起其他要做的测试，就加如清单。

3.新增一个测试,根据需求编写一个测试用例

4.运行所有的测试程序（有时候只需要运行一个或一部分），并失败；由于此时与测试相关的具体功能的类、函数等还没有开发，所以肯定会失败。

5.做一些小小的改动，这些改动其实只编写使测试能够通过的代码（没必要实现具体的功能代码细节），此时是尽快地让测试程序可运行，为次可以在程序中使用一些不合清理的方法。

6.运行所有的测试，并且全部通过

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

TDD原则

独立测试：不同代码的测试应该相互独立，一个类对应一个测试类（对于C代码或C++全局函数，则一个文件对应一个测试文件），一个函数对应一个测试函数。用例也应各自独立，每个用例不能使用其他用例的结果数据，结果也不能依赖于用例执行顺序。 一个角色：开发过程包含多种工作，如：编写测试代码、编写产品代码、代码重构等。做不同的工作时，应专注于当前的角色，不要过多考虑其他方面的细节。

测试列表(前面建立的to-do list)：代码的功能点可能很多，并且需求可能是陆续出现的，任何阶段想添加功能时，应把相关功能点加到测试列表中，然后才能继续手头工作，避免疏漏。

测试驱动：即利用测试来驱动开发，是TDD的核心。要实现某个功能，要编写某个类或某个函数，应首先编写测试代码，明确这个类、这个函数如何使用，如何测试，然后在对其进行设计、编码。

先写断言：编写测试代码时，应该首先编写判断代码功能的断言语句，然后编写必要的辅助语句。

可测试性：产品代码设计、开发时的应尽可能提高可测试性。每个代码单元的功能应该比较单纯，“各家自扫门前雪”，每个类、每个函数应该只做它该做的事，不要弄成大杂烩。尤其是增加新功能时，不要为了图一时之便，随便在原有代码中添加功能，对于C++编程，应多考虑使用子类、继承、重载等OO方法。

及时重构：对结构不合理，重复等“味道”不好的代码，在测试通过后，应及时进行重构。

小步前进：软件开发是复杂性非常高的工作，小步前进是降低复杂性的好办法。软件功能越复杂，这个步伐应该越小，在开始下一个工作之前，一定要保证前面已经完成的功能正确无误的可执行。

Kent Beck ．测试驱动开发(中文版)