通过FIT和FitNesse进行业务沟通

FIT（集成测试框架）和 FitNesse虽然都被用于敏捷项目进行集成测试（integration test）和验收测试（acceptance test），但很多人已经尝试将两者结合起来作为通用的测试框架。一些人指出FIT只能用于进行业务沟通或者客户沟通的交叉功能测试（cross- functional test），而且这一点是相当重要的。

要是FIT和FitNesse使用不当，多半是由于相关方面的共享经验不足引起的。

Naresh Jain指出目前还没有足够成熟的模式（pattern）和反模式（anti-pattern）：

我们是否应该用静态方式在各个环节中共享数据？如何设计Fixtures？继承与否？

在过去的几个月中，有些人已经分享了关于FIT和FitNesse的使用经验。James Shore描述了五种误用FIT的方式，其中他提到，人们尝试使用FIT来实现自动化，而这并非FIT所长，与客户沟通才是FIT所长。

当然，它被称作“集成测试框架”。但关键词在于“集成”，而不是“测试”。实际上，做为自动测试工具，Fit则显得相当劣 势。卓越的自动测试工具有很多，例如xUnit、Watir、Selenium，更不用说昂贵的屏幕抓取工具（screen scraper）了，它们都强于Fit。

Fit的长处——我所知道的，做得比其他工具要好的方面——“能够用表格提供示例”这一点会让客户觉得很舒服，Fit是用于客户沟通的卓越的工具。如果用它来自动化回归测试，将会令人捶胸顿足；如果用它来增强与客户沟通，将会使人眉开眼笑。

他总结了以下几点：

• Fit有利于沟通，不利于自动化测试
• 人们更多的使用Fit来进行测试自动化，而很少在沟通中使其发挥作用

Naresh Jain分享了一些关于FitNesse的模式与反模式。Naresh Jain同意了James Shore对FIT的看法，并且建议FIT不应该作为单元测试的替代品：

FitNesse不是QA测试工具。为了让FItNesse保持简单而且专司其职，我们只能用它来编写验收测试，而不是其他类型的测试。没有了对测试维护的支持，QA有效地使用它确实成了大问题。

此外，他建议FIT应该被用于交叉功能测试（cross-functional test）：

将基于FitNesse的验收测试应用于交叉功能测试团队成员间的协作，是一个帮助团队内部交流的好方法。它鼓励团队中的每个成员讨论业务实体，从而在故事初期就使用业务术语（domain language）。

Naresh Jain和James Shore都指出其他一些模式和反模式，他们也一致认可了FIT在软件项目中扮演的角色。

InfoQ之前的文章就涵盖了有关FIT和FitNesse的内容， 包括DbFit、FitNesse与.NET、FitNesse与Ruby以及一本关于FIT验收测试的初级读本。

查看英文原文： Communicating with Business Using FIT and FitNesse 译者简介： 包亮，一名普通的程序员，喜欢敏捷实践，喜欢"懒惰"，减少重复，尽可能让工作变得简单。几年来，一直通过网络汲取知识，也希望通过网络将知识与人分享 。志愿参与InfoQ中文站内容建设，请邮件至 [email protected]