测试驱动开发

出自 MBA智库百科(https://wiki.mbalib.com/)

测试驱动开发（Test-Driven Development）

　　测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

　　TDD将测试方案设计工作提前，在编写代码之前先做：从测试的角度来验证设计，推导设计；同时将测试方案当作行为的准绳，有效地利用其检验代码编写的每一步，实时验证其正确性。如此循环迭代，实现开发过程的“小步快走”。

　　TDD是一种分析方法。在TDD中，需求将完全表述为测试代码。这样，软件设计师的需求工作就不再是编写用例规约来覆盖用户的需要，而是迫使仔细思考要做什么和不做什么。特别是各种例外的情况，并用程序语言正式的写下来，即编写测试代码来捕获用户的需要。将需求整理为测试代码的形式。只要代码只要能够通过测试，就代表该代码设计已经能够满足客户需求。当然，这种肯定是有前提的。即测试代码能够完整的、精确的描述需求。另外，因为从使用者的角度写出测试代码。除要关心程序功能的本身外，还要对接口予以足够关注。便于更进一步明确需求。

　　TDD是一种设计方法。它用测试推进设计。必须清晰的定义程序的界面才能写出测试用例，通过编写测试用例，对其功能分解、使用过程、接口都要进行了设计。而且，这种从易用性的视角的代码设计，通常更符合后期开发的需求可测试的要求。对代码的内聚性的提高和复用都非常有益。这样的需求总是完整的被体现在了各个模块的接口上。即。保证对接口的使用能够正确无误的进行，就保证了这个模块的最终质量。

　　TDD是一种质量控制方法。开发者在项目的压力下往往忽略测试，而没有测试的软件增加了开发者的压力，TDD有一套完整的单元测试作为回归测试。保证现在能工作的代码将来也能工作，也可作为集成测试的检查点。TDD不是通常意义上的测试技术，它的目的也不是仅仅用来测试你的代码。TDD是把需求分析。设计，质量控制量化的过程!

　　TDD是一种重构和优化的方法。程序员总希望代码质量高，所以会不断地去改进，TDD确保改进和优化后的质量TDD是一种面向对象的开发方法。程序员必须清晰地定义程序的界面和功能才能写出单元测试用例，而不必关心逻辑是如何实现。

　　TDD是文档。TDD是通过写测试来写代码，当用这个视角去实践TDD时，测试用例会细化到以什么条件和参数、调用什么方法及会有什么返回值等，这就是文档，产生的测试用例代码就是对代码的最好的解释。说明了代码的运行机制，而且这种程序自我编档的方式也促进了交流和反馈。

　　TDD提供的测试集是信心的来源。快乐工作的基础就是对自己有信心。对自己的工作成果有信心：不用担心代码是否正确、还有没有严重bug、修改对其他部分有没有影响。

　　测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。测试驱动开发的基本过程如下：

　　①快速新增一个测试

　　②运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过

　　③做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法

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

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

　　简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。

　　测试驱动开发不是一种测试技术，它是一种分析技术、设计技术，更是一种组织所有开发活动的技术。相对于传统的结构化开发过程方法，它具有以下优势：

　　1)TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。因为关注用户反馈，可以及时响应需求变更，同时因为从使用者角度出发的简单设计，也可以更快地适应变化。

　　2)出于易测试和测试独立性的要求，将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，提高系统的可扩展性和抗变性。而且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。

　　3)将测试工作提到编码之前，并频繁地运行所有测试，可以尽量地避免和尽早地发现错误，极大地降低了后续测试及修复的成本，提高了代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。

　　4)TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。完整的测试会帮助我们持续地跟踪整个系统的状态，因此我们就不需要担心会产生什么不可预知的副作用了。

　　5)TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。

　　6)TDD可以减轻压力、降低忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。

　　7)快速的提高了开发效率。

　　TDD实质是一种编程技术．它间接地确保代码能彻底地被单元测试检查。但仍然需要参考传统的一些测试比如功能测试、用户验收测试、系统集成测试等等。一个好的传统测试能发现一个或多个漏洞。此理论同样适用于TDD。当一个测试失败时就必须进行改进，因为需要解决这个问题。更重要的是，当测试不再失败时．就可以清楚地知道成功了多少。TDD增强了信心因为它适应了预先定下的需求。

　　像传统的测试一样，项目风险越大，就要更彻底地进行测试，尽可能测试一切可以测试的东西『61。传统测试和TDD中都不可能为着完美而奋斗，代之的是测试系统的重要性，应该带着目的去测试、知道为什么要测试以及测试是在什么等级。TDD的代码测试覆盖率是100％．这是传统测试所不能保证的。

　　如果为一个功能值得写代码，那么一定值得测试。如果不值得测试．那又何必浪费时间去写一些无用的代码呢?TDD不能替代传统的测试，相反它定义一种验证方式来确保单元测试的有效性。