预计阅读本页时间：-
19.守护天使
“你不必为单元测试花费那么多时间和精力.它只会拖延项目的进度.好歹,你也是一个不错的程序员—单元测试只会浪费时间,我们现在正处于关键时刻.”
代码在快速地变化.每当你手指敲击一下键盘,代码就会被改变.敏捷就是管理变化的,而且,代码可能是变化最频繁的东西.
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
为了应对代码的变化,你需要持续获得代码健康状态的反馈:它是在做你期望的事情吗?最近一次修改有没有无意中破坏了什么功能?这时,你就带上守护天使,确保所有功能都能正常工作.要做到这样,就需要自动化单元测试.
现在,一些开发者会对单元测试有意见:毕竟,有”测试”这个词在里面,毫无疑问这应该是其他人做的工作.从现在开始,忘掉”测试”这个词.就把它看作是一个极好,编写能产生反馈的代码的技术.
先回顾一下,在过去大部分开发者是如何工作的:你写了一小块代码,然后嵌入一些输入语句,来看一些关键变量的值.你也许是在调试器中或者基于一些桩(stub)程序来运行代码.你手工查看所有的运行效果,来修复发现的所有问题,然后扔掉那些桩代码,或者从调试器中退出,再去解决下一个问题.
敏捷式的单元测试正是采取了相同,相似的过程,并且还让其更上一层楼.不用扔掉桩程序,你把它保存下来,还要让其可以自动化地持续运行.你编写代码来检查具体值,而不是手工检查那些感兴趣的变量.
用代码来测试变量的具体值(以及跟踪运行了多少个测试),已经是非常普通的做饭.你可以选择一个标准的测试框架,来帮助你完成简单的编写和组织测试的工作,如java的Junit,C#或.NET的Nunit,测试web service的HttpUnit,等等.实际上,对如何你可以想象到的环境和语言都有对应的单元测试框架,其中的大部分都可以从来Http://xprogramming.com/software.htm上的列表中找到.
只要有单元测试,就要让它们自动运行.也就是每次编译或者构建代码的时候,就运行一次测试.把单元测试的结果看作是和编译器一样—如果测试没有通过(或者没有测试),那就像编译没有通过一样糟糕.
接下来就是在后台架设一个构建机器,不懂获得最新版本的源代码,然后编译代码,并运行单元测试,如果有如何错误它会让你及时知道.
结合本地单元测试,运行每个编译,构建机器不断编译和运行单元测试,这样你就用有了一个守护天使.如果出现了问题,你会立刻知道,并且这是最容易修复(也是成本最低)的时候.
一旦单元测试到位,采用这样的回归测试,你就可以随意重构代码.可以根据需要进行试验,重新设计或者重写代码:单元测试会确保你不会意外地破坏如何功能.这会让你心情舒畅,你不用每次写代码的时候都如履薄冰.
单元测试是最受欢迎者的一中敏捷实践,有很多图书和其他资料可以帮你起步.如果你是一个新手,建议阅读<<单元测试之道>>(有java[Ht03]和C#[Ht04]版本).如果要进一步了解测试的一些窍门,可以看一下Junit Recipes[Rai04].
如果需要自动化地连接单元测试(和其他一些有用的东西),可以阅读<<项目自动化之道>>[Cla04].尽管它只要是关于java的,但也有类似的可以用与.Net环境或者其他环境的工具.
如果你仍然在寻找开始单元测试的理由,下面有很多.
? 单元测试能及时提供反馈.你的代码会重复得到锻炼.但若修改或者重写了代码,测试用例就会检查你是否破坏了已有的功能.你可以快速得到反馈,并很容易的修复他们.
? 单元测试让你的代码更加健壮.测试帮助你全面思考代码的行为,帮你练习正面和反面以及异常情况.
? 单元测试是有用的设计工具.正如我们在实践20中谈论到的,单元测试有助于实现简单的,注重实效的设计.
? 单元测试是让你自信的后台.你测试代码,了解它在各种不同条件下的行为.这会让你在面对新的任务,时间紧迫的巨大压力之下,找到自信.
? 单元测试是解决问题是的探测器. 单元测试就像是测试印制电路板的示波镜.当问题出现的时候,你可以快速地给代码发送一个脉冲信号.这为你提供了一个很自然的发现和解决问题的方法(见习惯35,第136页).
? 单元测试是可信的文档.当你开始学习新API的时候,它的单元测试是最精确的可靠的文档.
? 单元测试是学习工具.在你开始学习新API的时候,可以为这个API写个单元测试,从而加深自己的理解.这写学习用的测试,不仅能帮助你理解API的行为,还能保证你快速找到以后可能引入的,无法与现有代码兼容的变化.
使用自动化的单元测试.好的单元测试能够为你的代码问题提供及时的警报.如果没有到位的单元测试,不要进行任何设计和代码修改.
切身感受
你依赖与单元测试.如果代码没有测试,你会觉得很不舒服,就像是在高空作业没有系安全带一样.
平衡的艺术
? 单元测试是优质股,值得投资.但一些简单的属性访问方法或者价值不大的方法,是不值得花费时间进行测试的.
? 人们不编写单元测试的很多借口都是因为代码中的设计缺陷.通常,抗议越强烈,就说明越糟糕.
? 单元测试只有在达到一定测试覆盖率的时候,才能真正地发挥作用.你可以使用一些测试覆盖率工具,大致了解自己的单元测试的翻盖情况.
? 不测试越多质量就会越高,测试必须要有效.如果测试无法发现任何问题,也许它们就是没有测试对路.
