Fitnesse使用系列一

一、简介

按标准说法Fitnesse是一个验收测试框架，先不用理会这些貌似“高大上”的名词。看看它是如何介绍自己的。在手册文档的首页，定义了四种说明：1.是一个软件开发合作工具；2.是一个软件测试工具；3.是一个wiki；4.是一个webserver。

先从最有操作性的特征开始理解：一个webserver，也就是说肯定是以web方式访问的，就当是个网站好了；一个wiki，这就更具体些了。Wiki是一种百科全书式的站点，通常旨在介绍各种知识。那么fitnesse也类似，可以浏览它以获取我们需要的信息。这些信息当然不是凭空出来的，是我们自己录进去的，而且往往不是一个人录进去的。也就是说大家可以各自往里录入内容，那么当作一个论坛站点也未尝不可。只是fitnesse安全权限和日志方面比较弱，只能看到最后修改完的内容，哪些部分被修改过、谁修改的、修改了几次等等，就查不到了，不过这不是它的重点。能够让大家共同发信息、共同浏览信息，也就达到开发合作的目的了，所以尽管说的抽象，其实很简单。

到现在为止，定义中的1、3、4都明白了，那么这样看来和普通的站点并没有任何不同，而关键和有趣的就在于定义2——是一个测试工具。一个站点是如何成为一个测试工具的呢？实际上在fitnesse中有两种类型的页面（操作上不止两种，逻辑上可看作两种），一种叫做静态页面，这就完全是普通的html文字了。另一种叫做执行页面，特征是上面有个能够执行的按钮（有的页面是test按钮，有的页面是suite按钮，后面会深入介绍），我们可以通过修改一个页面的属性，来标明此页面是普通页面还是可执行页面。

二、实现原理

可执行页面是如何执行的呢？事实上，当我们点击这个按钮时，fitnesse自动去启动一个java命令，java–cp xxxx.jar;xxxx.jar {TEST_SYSTEM} {类名} {方法名}。其中的xxxx.jar是需要我们指定的；{TEST_SYSTEM}需要我们自己定义（默认是两种，fit和slim，理论上可以自定义扩展，我还没试，因为现在够用）；{类名} {方法名}从哪来呢？答案是页面中的表格，所以表格是fitnesse的一个关键因素，下一篇专门讲表格。

三、优点

能够想到把说明性文字和执行操作结合起来，这是我最佩服这个工具初始创意者的地方。根据经验，项目失败的很大可能性原因是信息传导不畅通。在传统的瀑布开发模式中，需求从用户传导到开发人员时，往往会走了样，这就导致产品接近开发完成时又局部返工甚至全盘返工，项目不失败才怪了。在敏捷模式中，强调的就是沟通与协作。需求变更要快速、准确的传达给开发人员。无疑，打电话是最快的，会议讨论其次，邮件通知再其次，文档变更是最慢效果最差的，恰恰又是用的最多的。为什么呢？因为前几种方式不好留证据、不好归档、不好给别人“吹嘘”（比如我们的管理多么多么规范，通过了XXX认证，通过了XXX验收......）。当然前几种也不是没有缺点，确实是各有利弊的事，在这不讨论这个，单说文档变更。文档变更后，即便通知（我这里说的通知不仅指手工发送的邮件，也包括版本管理工具的提醒等）到每个人，恐怕这个效果也是存疑的。因为通知没有任何约束力，谁看了，看了多少，懂了多少都无法保证。我们也都有这种体会，对于那些枯燥的模板式的文档，尤其是长篇的，真的很难认真去读。有时候宁愿打个电话问问怎么回事，也懒得去读这个。即便读了，大家的理解是否一致也难说。Fitnesse这种把文档和操作相结合的方式，就为我们提供了一种可能——在文档里不光写明要完成什么，还写明完成的效果是什么样的，而且可以执行测试以验证这个效果。这就是验收测试（Acceptence Testing）。大家的理解是否正确、一致，由测试的红绿条决定。绿了就合格，红的就是有问题（也许需求不合适，也许测试用例不合适，也许代码有bug，总之看到红条就提醒大家一起找原因）。在我看来这正是fitnesse的价值所在，而不要把它仅当作自动化测试工具来看待。自动化测试工具或框架有很多，而兼具沟通工具和测试工具的就颇为可贵了。