TDD与VTDD系列(三):TDD概述

什么是TDD
    TDD是Test-Driven Development的缩写,即测试驱动开发。TDD的基本思路是利用测试来推动开发的进行,并不是单纯的测试过程。TDD是极限编程的核心之一,但TDD也可以单独运用。


TDD的优势
    明确需求:在软件开发过程中,需求常常是易变且不易描述的。项目的整体需求最终会细化为代码的需求,即每个代码单元都有其具体的功能要求。整体的需求不明确,代码的需求自然也不能明确。即使整体需求完全明确,细化过程也可能导致某些代码的需求不明确。TDD首先编写测试代码,测试代码实际上是产品代码的使用实例,是对产品代码的需求描述,这个描述是明确的、无二义的、可执行的。

    明确设计:通过编写测试代码,对产品代码的功能、使用方式都进行了设计,这种设计是从使用角度进行的,更符合后期开发的需要。这些设计限定了产品代码的外延范围,使各个代码单元功能单纯化,提高了可测试性、可维护性、可扩展性、可复用性。

    形成文档:很多程序员不喜欢写文档,但阅读、使用他人的代码时却要求文档。即使是自己写的代码,过一段时间再阅读、修改,没有文档也会很困难。测试代码就是一种详细文档,记录了代码单元的使用方法,以及什么输入会产生什么输出。文档是可执行、可验证的,即使代码频繁更新,文档与代码仍然会保持一致。

    自信编程:如果缺少测试,那么,代码是否正确?如果代码需要修改,会对其他部分造成影响吗?测试集会保证代码所做的,与程序员所想的一致。代码修改后,执行回归测试马上就会确认是否破坏原有功能,是否影响其他代码,从而更自信地工作。

    提高效率:TDD在编码之前先编写测试代码,每一个最小的功能点都能立即验证是否正确,代码错误可在第一时间发现和定位,大幅减少调试。如果没有测试,编码后的调试时间往往比编写代码的时间还要多得多。
强制测试:TDD要求先编写测试代码,再编写产品代码,可以避免产品代码写完后,程序员的注意力转移到其他代码的编写,从而忽略测试。


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

    测试列表:代码的功能点可能很多,并且需求可能是陆续出现的,任何阶段想添加功能时,应把相关功能点加到测试列表中,然后才能继续手头工作,避免疏漏。

    测试驱动:即利用测试来驱动开发,是TDD的核心。要实现某个功能,要编写某个类或某个函数,应首先编写测试代码,明确这个类、这个函数如何使用,如何测试,然后在对其进行设计、编码。
先写断言:编写测试代码时,应该首先编写判断代码功能的断言语句,然后编写必要的辅助语句。

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

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

    小步前进:软件开发是复杂性非常高的工作,小步前进是降低复杂性的好办法。


TDD三条军规
    Object Meentor公司总裁,极限编程领域资深顾问Robert C. Martin提出了TDD三条军规:
    1. 除非这能让失败的单元测试通过,否则不允许去编写任何的产品代码。
    2. 只允许编写刚好能够导致失败的单元测试(编译失败也属于一种失败)。
    3. 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
    这三条军规简单明了地阐述了TDD过程,下一节举例说明。

阅读更多
个人分类: TDD与VTDD
上一篇TDD与VTDD系列(二):CppUnit的改进与使用(2)
下一篇TDD与VTDD系列(四):简单实例演示TDD过程
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭