FIT 简介

Fit: Framework for Integrated Test

优秀的软件需要协作和沟通,在开发过程中,客户如何才能知道他们的程序员如何正确处理了事情呢?而程序员又如何知道客户究竟想的是什么呢?测试人员如何才能知道什么是正确的而什么又是错误的?让这些小组能有效和精确地交流应该是团队创建伟大软件的一个目标。

FIT就是一个用于增强交流和协作的工具。FIT创建了一个在客户和程序员之间的反馈循环。FIT让客户和测试人员可以使用诸如Microsoft Office之类的工具来给出程序应当如何表现的例子——而无需成为直接编码的程序员。FIT自动针对实际的程序检测那些例子,这样就在业务世界和软件工程世界之间建立了一个简单而且有效的桥梁。

有了FIT,客户可以通过将他们的主题相关的专业知识和想象引入实际的工作中,给开发过程直接提供更多的指导。客户所获得的更多关于目前产品开发中正在发生的东西的可见性,能让他们随时控制项目避免偏离目标。

==FIT如何工作==

FIT通过读取由类似MicrosoftWord之类的工具生成的HTML文件中的表格来进行工作。每一个表格通过一个程序员写的“装置”来进行解释。装置将通过运行实际的程序来检测表格中的例子。

在这个例子中,团队要建立一个产品用于计算职工的薪水。团队已经一起创建了一个包含一些如何计算小时薪水例子的FIT文档。

表格包含了例子。第一行告诉了FIT如何读取表格。第二行给出了例子的头,剩下的行给出了例子。例如,在第一个表格中的例子说:“如果某人工作了40个工时同时没有休息时,那么就付给$20每小时的薪水,然后他的总薪水是$800。”

(虽然这个例子只使用了一个简单的表格格式来展示计算的结果,其实还有很多不同的表格格式可以使用。)

FIT自动针对软件检验表格中的例子。在我们这个例子中,对前两个测试案例,软件给出了正确的解,所以FIT把表格单元标示为绿色。在最后一个测试案例中,软件给出了错误的解,所以FIT把这个表格单元标记为红色。这个软件说职员的总薪酬是$1,040,而期望的值是$1,360。


为了能让FIT能使用这个表格工作,团队的程序员创建了一个“装置”来告诉FIT如何和他们的软件交流。情况类似下面:

程序员使用了一个ColumnFixture来将表格中的列映射到装置中的变量和方法上。前三列,提供了信息,对应于装置中的变量。最后一列,包含期望的值,对应于装置中的Pay()方法。要计算答案,程序员使用他们程序中的WeeklyTimesheet类。

==总结==

FIT给予了客户和程序员一个关于软件的精确交流的方法。客户所给的具体的例子让程序员能深刻理解将要构建的产品。程序员的对于装置的工作和软件可以让客户给出不同的例子进行试验来获取对于软件如何真正工作更深入的了解。这样通过一起工作,整个团队可以学会更多关于产品的内容并产生更好的结果。

为什么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这样的起始工作。

Web 2.0需要测试

原文: Web 2.0 needs testing 作者:Sam Newman

翻译:ShiningRay @ Nirvana Studio

我带着很多怀疑,耐着性子看完了Cal Henderson的高度富有娱乐性的(而且推荐大家观看)
构建Flickr作坊》,
从中听说自动化测试在他们的优先级列表中并不是特别地高
(有趣的旁白——Cal还认为面向对象编程是“神经错乱的”,所有的“健全”的代码则在“一超大函数”编程和OO之间的空间中存在)。
“测试Web应用”Cal说,“很困难”。其实这是一个普遍的误解。像任何其他应用的类型一样,只要你针对测试性设计了结构,测试是很容易的。然而,同时如果你采用了针对Web应用的测试而制作的测试工具(FITFITnesse, 以及Selenium都是很好的例子),那么即使那些没有带着测试的概念写的应用都没有借口说不利用他们进行开发。

但是现在放在我们面前的是Flickr这样一个姿态鲜明成功的应用,我只能假设自动化测试还存在一个更加成熟的途径。这种对自动化测试的放任自由的方式是不是很普遍呢?

让我们看看这另一条道路。如果你没有自动化测试,你要么手工进行测试(这意味着更长的发布时间)要么干脆不测试。如果你要着眼于交付有质量的产品,这也许意味着你最终还是要做很多手工测试,而这些测试本来可以自动化地更快完成的,甚至只要你想,可以在
在每一次的代码提交中完成

Web的架构产生了一个及早的快速发布、同时有一个经常发布的过程这样的想法。有了Web,你所有要关心的最终目标环境仅仅是你的服务器和客户端的浏览器。推出一个发行版真的可以像Flickr使用的“一点部署”(One-click Deployment)。有了一个成熟的测试框架,如果有必要的话,还可以办到一天之内多次直接给你的用户发布。

测试也许看起来不怎么好玩——但是一旦你明白了它意味着你可以更频繁地对你的用户发布更酷的功能,同时你可以在修复Bug上花费更少的时间,那么我们都可以去更加喜欢书写测试了。