`
walkes
  • 浏览: 26948 次
社区版块
存档分类
最新评论

关于测试驱动开发(转)

阅读更多
TDD的最终目标:整洁可用的代码 Clean code that works

测试驱动开发的对立面:体系结构驱动的开发(Architecture-driven Development)
TDD首先解决可用的问题,然后考虑整洁,ADD正好相反。

TDD的工作流程:
(1)写一个测试程序
(2)让测试程序编译通过
(3)运行测试程序,发现不能通过
(4)让测试程序可以运行
(5)消除重复设计,优化设计结构
个人理解:
(1)为了能方便地写测试程序,往往需要先写出被测程序函数的Signature
(2)第4步的含义应该是“修改被测程序,以便符合测试程序的断言要求(Assertion)”
(3)第5步也很重要,说明TDD并不否认良好设计的重要性,只是工序上的问题,也就是说,
TDD认为:应该先让代码能工作,再让代码更整洁。

依赖关系与重复设计
依赖关系是各种规模的软件开发中的关键问题。
例子:使用某个数据库厂商的SQL方言,导致系统依赖该数据库产品,无法移植到其他数据库系统。

如果依赖关系方面有问题,表现就是重复设计。
重复设计就是重复的逻辑设计,也就是相同的代码在多个地方出现。

消除重复设计就是消除依赖关系。

To-do List工作方法:
列出需要完成的任务,做完一个划掉一个。
避免过多的头绪影响对当前问题的全神贯注。

三角法(Triangulation)
三角法是让测试运行的办法之一,让测试利落运行的另外两个方法是:伪实现和显明实现。
三角法是TDD的最保守的实现方法。
仅当Test Case达到2个或更多,并且第2个Case需要更一般化的解决方案时,才对代码实施一般化(泛化/抽象?)。
核心思想是:设计时考虑需要支持哪些变化,如果没有看到新的需求,就不要修改现有代码。

重构
TDD对于重构有一个“时时做,一次做一点”的思想。
“为明天编码、为今天设计”(教科书上说“编码为今天,设计为明天”)
“不为代码的将来考虑,你的代码反而更有可能适应将来的需要”
个人理解:
如果一次做太多,可能导致过度设计;
如果老不做,到了被迫做的时候又会畏难。

TDD的局限:
不要指望用TDD代替其他类型的测试:性能测试、安全性测试、压力测试、可用性测试。
UI测试不太适用。
TDD的原则是先写测试代码再写实现代码,所以不要指望在一个已经编码很多的项目中途采用TDD。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics