为什么Flickr不进行自动化测试?

原文:为什么Flickr不进行自动化测试? — Carlos Villela @ 8:00 pm

翻译:ShiningRay

Sam Newman 惊讶于(中文版) Flickr没有使用很多自动化测试,因为“作为一个姿态鲜明和成功的应用,我只能假设自动化测试还存在一个更加成熟的途径”。

事实上,当看到的时候我也有点惊讶,不过我想我知道他们为什么不真正十分关心测试的原因,我的反应是他们不仅仅只是一群过时.COM时代的普通牛仔,在一边把代码仍在墙上一边看看堵住了什么——这些人常常被一般的敏捷人(agilist,还和拳击手pugilist押韵?)在会议和论文上批评他们没有测试自己的代码并被告知这样做更好。也许有某些原因可以不去麻烦测试,我在这里要尝试在这里解释他们,当然我明白这篇贴子可能有点过激。首先,让我们提出在一个新的项目阶段开始后,两种不同的场景,其中数字代表某种在给定的期间内的想象的成本单元:

场景 A B
开发 10 10
自动化测试 8 0
维护 2 10

假设其他条件均相同,同时代码是由合格的开发者——当然Flickr的家伙们肯定都是——很好地书写的,这样的表格看起来似乎可信:其中A使用了自动化测试来发现错误,节省了维护的时间,而B单独把时间花费在维护上,产生了同样的结果(至少在这个阶段)。

A中,公司需要预付钱来建立可用的测试套件并运行,这样他们就不用对未来的维护多花费这笔钱。现在飞过来了叉子和火把,并且要置我于死地,但是这是一个糟糕的财政决定,除非写自动测试的成本比进行所有的维护的成本要低,但后者的成本可能会扩散。然而这个成本不低的风险,至少在我的经验里,看起来比大多数公司所愿意接受的要高的多,因此我们从多数——如果不是全部的——敏捷人那里听到关于这个方式的好的结果。

现在再把这小段话引用一下:我是一个自动化测试的爱好者因为我见过维护软件有多烦人 ,在几个月都不停做这事,消耗尽了我最后一点出现在我可怜精神中的愉快感。我则更偏好写全新的代码,即使代码没有在最终的产品环境中用到,就像测试代码一样,而不是经历另一个令人沮丧的一天不停地在调试器上一步步移动。 我确定Sam和大多数正在阅读本文的人都是同一条船上的。

B,在我的理论中,就是Flickr所正在做的:较少的预期投入和随着时间流逝的更多的维护成本。
作为一个开始阶段(嗯,不管怎样,在他们被Yahoo收购之前),这很有意义:整个启动阶段就是让你可以去做更有风险的事情,同时某种程度上他们臆测自动地测试任何东西除了小部分重要的(冒烟测试?)并不如立刻把代码颁布出门,且快速,并强制听取用户的反馈并作出反应来得更加重要。这也许要求对对细节和承诺的关注保持一种疯狂的关注程度,这是很稀罕的,不过我要补充一点,这却是我所总结他们成功的原因的一个重要的部分。

正如Joel Spolsky所写的,大概三年前,针对一个类似的情况:

你需要某种经济模型来决定如何花费你有限的资源。你不可能通过说 “压力测试是一个没脑子的东西”或者“服务器也许还可以撑一下。”之类的话来作出可靠的理智的决定。这些都是感情用事的脑子的大便,而非分析。同时在长期的运行中,我们科学家将会获胜。

所以,我不确定谁是正确的,这里:我知道我所参与的大部分项目,在没有经过自动化测试和大量的测试覆盖率保持工作的情况下,本应该完全失败的(某些事实上就是)。但是再说,我从来没有进行过任何像Flickr这样的起始工作。

发表评论

电子邮件地址不会被公开。 必填项已用*标注