追逐代码质量: 决心采用 FIT

核心提示：JUnit 假定测试的所有方面都是开发人员的地盘，而集成测试框架（FIT）在编写需求的业务客户和实现需求的开发人员之间做了协作方面的试验，追逐代码质量: 决心采用 FIT，这是否意味着 FIT 和 JUnit 是竞争关系呢？绝对不是！代码质量完美主义者 Andrew Glover 介绍了如何把 FIT 和 JUnit

JUnit 假定测试的所有方面都是开发人员的地盘，而集成测试框架（FIT）在编写需求的业务客户和实现需求的开发人员之间做了协作方面的试验。这是否意味着 FIT 和 JUnit 是竞争关系呢？绝对不是！代码质量完美主义者 Andrew Glover 介绍了如何把 FIT 和 JUnit 两者最好的地方结合在一起，实现更好的团队工作和有效的端到端测试。

　　在软件开发的生命周期中，每个人都对质量负有责任。理想情况下，开发人员在开发周期中，用像 Junit 和 TestNG 这样的测试工具保证早期质量，而质量保证团队用功能性系统测试在周期末端跟进，使用像 Selenium 这样的工具。但是即使拥有优秀的质量保证，有些应用程序在交付的时候仍然被认为是质量低下的。为什么呢？因为它们并没有做它们应当做的事。

在客户、（编写应用程序需求的）业务部门和（实现需求的）开发团队之间的沟通错误，通常是摩擦的原因，有时还是开发项目彻底失败的常见原因。幸运的是，存在一些方法可以帮助需求作者和实现者之间尽早 沟通。

FIT 化的解决方案

　　集成测试框架 （FIT）是一个测试平台，可以帮助需求编写人员和把需求变成可执行代码的人员之间的沟通。使用 FIT，需求被做成表格模型，充当开发人员编写的测试的数据模型。表格本身充当输入和测试的预期输出。

图 1 显示了用 FIT 创建的结构化模型。第一行是测试名称，下一行的三列是与输入（value1 和 value2）和预期结果（trend()）有关的标题。

　　图 1. 用 FIT 创建的结构化模型

好消息是，对于编程没有经验的人也能编写这个表格。FIT 的设计目的就是让消费者或业务团队在开发周期中，尽早与实现他们想法的开发人员协作。创建应用程序需求的简单表格式模型，可以让每个人清楚地看出代码和需求是否是一致的。

清单 1 是与图 1 的数据模型对应的 FIT 代码。不要太多地担心细节 —— 只要注重代码有多么简单，而且代码中没有包含验证逻辑（例如，断言等）。可能还会注重到一些与表 1 中的内容匹配的变量和方法名称；关于这方面的内容后面介绍。

　　清单 1. 根据 FIT 模型编写的代码

package test.com.acme.fit.impl;

import com.acme.sedlp.trend.Trender;
import fit.ColumnFixture;

public class TrendIndicator extends ColumnFixture {

  public double value1;
  public double value2;

  public String trend(){		
    return Trender.determineTrend(value1, value2).getName();
  }
}

清单 1 中的代码由研究上面表格并插入适当代码的开发人员编写。最后，把所有东西合在一起，FIT 框架读取表 1 的数据，调用对应的代码，并确定结果。

　　FIT 和 JUnit

FIT 的美丽之处在于，它让组织的消费者或业务端能够尽早参与测试过程（例如，在开发期间）。JUnit 的力量在于编码过程中的单元测试，而 FIT 是更高层次的测试工具，用来判定规划的需求实现的正确性。

例如，虽然 JUnit 擅长验证两个 Money 对象的合计与它们的两个值的合计相同，但 FIT 可以验证总的订单价格是其中商品的价格减去任何相关折扣之后的合计。区别虽然细微，但的确重大！在 JUnit 示例中，要处理具体的对象（或者需求的实现），但是使用 FIT 时要处理的是高级的业务过程。　

这很有意义，因为编写需求的人通常不太考虑 Money 对象 —— 实际上，他们可能根本不知道这类东西的存在！但是，他们确实要考虑，当商品被添加到订单时，总的订单价格应当是商品的价格减去所有折扣。

FIT 和 JUnit 之间绝不是竞争关系，它们是保证代码质量的好搭档，正如在后面的 案例研究 中将要看到的。

测试用的 FIT 表格

表格是 FIT 的核心。有几种不同类型的表格（用于不同的业务场景），FIT 用户可以用不同的格式编写表格。用 Html 编写表格甚至用 Microsoft Excel 编写都是可以的，如图 2 所示：