翻译自TDD-byexample
作者Kent Beck, Three Rivers Institute
有删减
表现 #
测试驱动开发核心: #
- 除非你有失败的自动化测试千万不要写一行新代码
- 拒绝重复
这两个的简单原则构成了TDD的核心,但是他能规划一个复杂的项目乃至一个团队.这里有一些TDD的建议.
- 你的项目设计不能太过全面,只要有一个模型或者相应的功能,然后你让你的测试代码测试你模型,通过反馈来完善你设计.
- 你必须自己写测试代码,你不能依靠别人来每天帮你修改无数次测试
- 你的开发环境必须能监控到代码的微小的变化
- 你测试代码必须要非常简单,复杂的测试代码说明你的程序有问题
根据核心我们总结了一种具体的测试方法:红绿重构法
红 --- 写一段测试代码让他无法通过,有时候可以编译都通过不了
绿 --- 写尽可能少的代码让测试代码通过,通过后保存一下系统状态
重构 ----删掉所以重复的代码只要让测试代码还能通过
红绿重构法是TDD最高作战计划,他看起来很笼统,其实他具体到了每一行代码.
如果我们按照TDD这种开发模式,我们会有什么好处呢
- 如果我们新功能出了问题,质检部门能很快的将新代码回归到上一个稳定代码,尽快避免损失
- 如果代码的测试能将"惊喜"挖的差不多的话,项目经理能更准确的知道客户在使用过程中碰到的各种奇葩问题
- 如果我们的测试能够让各种技术交流变得更加清晰,我们能更快的进行技术排错
- 如果我们项目的bug更少的话,我们的项目能变得更加灵活,我们可以很轻松的添加新功能呈现给我们顾客
这些概念看起来很简单,但是我们的动机呢?为什么我要在写代码过程添加自动测试?为什么我要每次迈小小的一步在我能够做到更多的情况下?两个字:担忧
担忧 #
测试驱动开发是一种管理你担忧的一种编程方式,担忧也不是说就是坏东西,自信过头也不好,但是恐惧给你一种在项目开头时,“我看不到这个项目的能够完成”,这种感觉,
假如说痛给你一个"停下来"的信号,担忧给你一个"要认真"的提醒信号,但是与之而来的,担忧带来一些你消极的影响
- 让你变得迟疑
- 让你开始抱怨
- 让你开始不愿交流
- 让你开始不想接受反馈
这些没有一个对你编程有帮助,尤其是当你在编一个比较复杂的软件的时候,所以你怎么来面对这些呢
- 抛弃迟疑,学习快速有效的编程
- 不要拖沓,跟别人交流思路要清晰
- 不要拒绝反馈,去寻找更多有帮助的反馈
想象一下编程就是你提桶着水过河,当你水桶很小的时候,你轻微的震动没什么影响,但是当你的水桶很大,而且水很满的时候,你会很累,你无时无刻不在担心你的水是否会撒掉.
这个时候你需要一个运水的管道,每当你用水桶打一点水,你可以把他放进管道,确保这点水安全到达对面,继续打水.
这个测试驱动开发中的测试就是运水的管道,一旦你的测试通过,你就知道水已经送过去了,不需要担心水到不到对岸了,你就这样一步一步让所以的工作正常进行,但你测试失败的时候,专注于让他通过,这样下一个下一个,慢慢的我们接触到了编程难题,你的测试慢慢覆盖到整个项目.
TDD给你一种控制的能力.当年在外面开车碰到下雪,你可以迅速停车去做其他琐事,当雪停了,你可以继续开车.
所以很多人说他们使用TDD对于项目的变化更有控制力.
接下来我会用一个例子来详细的介绍TDD开发的流程.
由于原作者是用
java来介绍的,本人用Python较多,所以就用自己写的一个项目sample来做介绍,详细链接
接下来翻译一下书后面关于TDD的一些答疑
TDD答疑
#
我希望在这里提出一些或大或小问题帮助你思考如何将
TDD引入到你的个人实践里面
你的测试步伐到底该多大? #
这里有两个引申过来的问题
- 每个测试覆盖范围该多大
- 当你重构时到底有要迈多大步伐
你的测试可以覆盖到你写的每一行代码和你每下一构,你的测试也可以覆盖你上百行代码和你几个小时后的重构,但是哪个才是我们该写的测试呢.
从某方面来看,你应该要能做到其中一个测试,虽然TDD宗旨就是每一步都非常清晰,每一步伐都要求非常小,但是我们对软件驱动开发的经验会使这个步伐或多或少产生影响.
当你开始重构的时候,你应该准备好将一个重构分成很多小的步伐.重构很有可能会发生错误,你把坑都踩一遍然后填上,然后你接下来重构的可能性就会小很多.一旦你完成每次用多个小步伐的一个重构,你可以试试遗漏一些步骤.