初步认识TDD

  TDD,测试驱动开发(Test Driven Development)是极限编程中倡导的程序开发方法,以其倡导先写测试程序,然后编码实现其功能得名。本文将对TDD有一个较为系统的认识。

   基础属性

  起源:20世纪90年代。

  性质:一种由极限编程倡导的程序开发方法。

  中心思想:先写测试程序,然后编码实现其功能。

  目的:取得快速反馈并使用“illustrate the main line”方法来构建程序。

   开发方式

  1、戴两顶帽子的开发方式

  (1)戴实现功能的帽子,在测试的辅助下,快速实现其功能。

  (2)戴上重构的帽子,在测试的保护下,通过去除冗余的代码,提高代码质量。

  2、中心思想

  测试驱动着整个开发过程。

  (1)驱动代码的设计和功能的实现。

  (2)驱动代码的再设计和重构。

   测 试

  1、特征

  测试驱动开发是需求分析和详细设计的范畴,在代码基本完毕以后,并且这些测试也成为单元测试的一个部分。

  2、要点

  可读性甚至比生产代码更重要,明确,简洁,足够的表达力。

  3、一般模式

  构造数据 — 操作数据 — 检验数据

  4、遵循的规则

  (1)单个测试中断言数量应该最小化,可以快速方便地理解其结论。

  (2)每个测试一个概念,即每个测试函数只做一件事。

  (3)F.I.R.S.T原则

    快    速(First):能够快速运行。

    独    立(Independence):可单独运行每个测试,也就是说可以任何顺序运行测试。

    可重复(Repeat):在任何环境中测试均能通过。

    自动验证(Spontaneous Verification):应有布尔值输出。

    及    时(Timely):应在生产代码之前编写。

   TDD三定律

  1、在编写不能通过的单元测试前,不可编写生产代码。

  2、只可编写刚好无法通过的单元测试,不能编译也算不通过。

  3、只可编写刚好足以通过当前失败测试的生产代码。

  总的来说就是先写测试再写生产代码,写一个测试就应该立即写它的实现代码。

   评 价

  1、正面

  (1)可以有效避免过度设计带来的浪费。

  (2)可以让开发者在开发中拥有更全面的视角。

  (3)确保所有需求都能被照顾到。

  2、负面

  (1)过度关注用例和测试案例,而不是设计本身。

  (2)可能会导致单元测试的覆盖度不够,比如可能缺乏边界测试。

  (3)放慢开发实际代码的速度。

  (4)对于GUI,资料库和Web应用而言,构造单元测试比较困难,若强行构造单元测试,反而会给维护带来额外的工作量。

  (5)test case  并没有那么好写,如果说我们开发的Test Case是用来保证我们代码实现的正确性,那么,谁又来保证我们的Test Case的正确性呢?

   我的感悟

  使用TDD完成过一个小游戏项目,感觉TDD的开发方式让我觉得有了另一种思维开发方式,从这个项目的各个功能点来写测试,并通过测试来实现我们的生产代码。以前完成一个项目是自上而下的思维,就是站在一个宏观的角度,来全局总览这个项目,那么最开始的时候就得考虑很多,这个时候最容易陷入细节误区了,即会细化到某些细节难以控制自己的思维。现在接触TDD之后,给我的感觉就是自下而上了。不考虑全局的东西,我一个小功能一个小功能的实现,曾经是从树顶来做,现在是从树根了,每一个根节点实现了我往上一层一层加起来,最后就是一棵树了,哈哈~

 

ps:本文内容若是有误或者迷糊,还请指正或指出。

posted @ 2015-01-02 14:13  w_fsovereign  阅读(3721)  评论(0编辑  收藏