《TDD.docVIP

测试驱动开发（Test-driven development）是现代计算机软件开发方法的一种。利用测试来驱动软件程序的设计和实现。测试驱动开始流行于20世纪90年代。测试驱动开发是极限编程中倡导的程序开发方法，方法主要是先写测试程序，然后再编码使其通过测试。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。 测试驱动开发的比喻。开发可以从两个方面去看待：实现的功能和质量。测试驱动开发更像两顶帽子思考法的开发方式，先戴上实现功能的帽子，在测试的辅助下，快速实现正确的功能；再戴上重构的帽子，在测试的保护下，通过去除冗余和重复的代码，提高代码重用性，实现对质量的改进。可见测试在测试驱动开发中确实属于核心地位，贯穿了开发的始终。 测试驱动开发中测试的特征 测试驱动开发中的测试和一般意义上单元测试的区别。一般意义上的单元测试是对实现了的功能的验证，功能和接口已经在此以前就完毕，属 于测试的范畴；而测试驱动开发中开发者进行的单元测试时，需要考虑被实现的模块的功能和接口，在单元测试完毕以后，模块的功能和接口的设计和推敲基本完 毕，尔后，开发者在测试的辅助下实现接口及其对应的功能，这里的单元测试属于需求分析和详细设计的范畴，在代码基本完毕以后，这些测试也成为单元测试的一个部分。 测试驱动开发相关讨论 正面评价 可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。 可以让开发者在开发中拥有更全面的视角,避免过度实现带来的浪费。 负面评价 开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。 会放慢开实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品質两个方面，单纯的代码速度可能不能完全代表开发速度。 对于GUI,資料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。 使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。 测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。 浅谈测试驱动开发（TDD） 测试驱动开发(TDD)是极限编程的重要特点，它以不断的测试推动代码的开发，既简化了代码，又保证了软件质量。本文从开发人员使用的角度，介绍了 TDD 优势、原理、过程、原则、测试技术、Tips 等方面。 背景 一 个高效的软件开发过程对软件开发人员来说是至关重要的，决定着开发是痛苦的挣扎，还是不断进步的喜悦。国人对软件蓝领的不屑，对繁琐冗长的传统开发过程的 不耐，使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术，提供一些比较高效、实用的软件过程开发方法。其中比较基础、关键的一个技术就是 测试驱动开发（Test-Driven Development）。虽然TDD光大于极限编程，但测试驱动开发完全可以单独应用。下面就从开发人员使用的角度进行介绍，使开发人员用最少的代价尽 快理解、掌握、应用这种技术。下面分优势，原理，过程，原则，测试技术，Tips等方面进行讨论。 1. 优势 TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。 需求向来就是软件开发过程中感觉最不好明确描述、易变的东西。这里说的需求不只是指用户的需求，还包括对代码的使用需求。很多开发人员最害怕的就是后期还要 修改某个类或者函数的接口进行修改或者扩展，为什么会发生这样的事情就是因为这部分代码的使用需求没有很好的描述。测试驱动开发就是通过编写测试用例，先 考虑代码的使用需求（包括功能、过程、接口等），而且这个描述是无二义的，可执行验证的。 通过编写这部分代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。 开发人员通常对编写文档非常厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而测试驱动开发过程中产生的测试用例代码就是对代码的最好的解释。 快乐工作的基础就是对自己有信心，对自己的工作成果有信心。当前很多开发人员却经常在担心：“代码是否正确？”“辛苦编写的代码还有没有严重bug？”“修 改的新代码对其他部分有没有影响？”。这种担心甚至导致某些代码应该修改却不敢修改的地步。测试驱动开发提供的测试集就可以作为你信心的来源