初步认识TDD

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

   基础属性

　　起源：20世纪90年代。

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

　　中心思想：先写测试程序，而后编码实现其功能。

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

   开发方式

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

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

　　（2）戴上重构的帽子,在测试的保护下,经过去除冗余的代码,提升代码质量。

　　二、中心思想

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

　　（1）驱动代码的设计和功能的实现。

　　（2）驱动代码的再设计和重构。

   测 试

　　一、特征

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

　　二、要点

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

　　三、通常模式

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

　　四、遵循的规则

　　（1）单个测试中断言数量应该最小化，能够快速方便地理解其结论。

　　（2）每一个测试一个概念，即每一个测试函数只作一件事。

　　（3）F.I.R.S.T原则

　　　　快    速（First）：可以快速运行。

　　　　独    立（Independence）：可单独运行每一个测试，也就是说能够任何顺序运行测试。

　　　　可重复（Repeat）：在任何环境中测试均能经过。

　　　　自动验证（Spontaneous Verification）：应有布尔值输出。

　　　　及    时（Timely）：应在生产代码以前编写。

   TDD三定律

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

　　二、只可编写恰好没法经过的单元测试,不能编译也算不经过。

　　三、只可编写恰好足以经过当前失败测试的生产代码。

　　总的来讲就是先写测试再写生产代码，写一个测试就应该当即写它的实现代码。

   评 价

　　一、正面

　　（1）能够有效避免过分设计带来的浪费。

　　（2）可让开发者在开发中拥有更全面的视角。

　　（3）确保全部需求都能被照顾到。

　　二、负面

　　（1）过分关注用例和测试案例,而不是设计自己。

　　（2）可能会致使单元测试的覆盖度不够,好比可能缺少边界测试。

　　（3）放慢开发实际代码的速度。

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

　　（5）test case  并无那么好写,若是说咱们开发的Test Case是用来保证咱们代码实现的正确性，那么，谁又来保证咱们的Test Case的正确性呢？

   个人感悟

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

 

ps：本文内容如果有误或者迷糊，还请指正或指出。