1.4　利用验收测试驱动开发，使用FitNesse测试GUI
现在已经是我们自动化之旅的第8个月了，程序员已经建立了一个自动化单元测试的实用库。对于应用程序的核心区域我们已经进行了冒烟测试，覆盖微量代码的大约100个JUnit测试已经完成了。但是中间层还什么都没有，TDD此时变成了一个空壳。现在我们开始对自动化测试金字塔的中间层进行填充。
1.4.1　内存内测试
我们的金融理财产品有许多复杂的算法，这可以通过在内存中提供输入来进行测试。与单元测试相比，这种测试的级别要高很多，但我们还是不想通过GUI来进行测试，因为其速度慢、成本高。我们发现可以很迅速、方便地编写FitNesse夹具（fixture）来自动进行这类测试。在客户测试层次，我们开始用FitNesse测试来驱动新的用户故事的开发。这些测试使用夹具在内存中构建测试输入，并把这些输入发送到应用层代码，就如同产品在实际使用时进行的输入一样。然后夹具会返回代码的实际输出，并把它与FitNesse表中的期望结果进行对比。
测试人员和客户填写FitNesse测试用例，之后程序员用夹具来自动运行它们。这意味着我们需要交流！提高团队的交流能力是使用这种工具进行自动化测试的最大好处之一。我们测试人员与产品所有者和其他利益相关者坐在一起分析每个用户故事预期的和非预期的行为。我们将这些用户故事转化为FitNesse测试用例表，并与客户核对以保证当测试用例通过测试的时候能够满足客户的要求。我们与开发人员核对测试，以保证我们清楚需求并保证测试设计与代码设计兼容。开发人员编写夹具来自动运行测试。这一过程在单个用户故事的很多小的迭代中不断重复，直到开发和测试都完成。
1.4.2　使用数据库的测试
我们的应用是数据密集型应用，我们想自动运行更加端到端（end-to-end）的测试。我们也可以使用FitNesse在数据库中构建测试数据，并使用遗留代码在它上面运行，以此来测试遗留代码。
这种类型的测试脚本编写和维护都更加昂贵。作为FitNesse的初学者，我们犯了一些错误，如，不知道将测试组件模块化，而这可以通过FitNesse中现有的部件来完成。我们彻底违反了代码设计中的“不要重复自我”准则。例如，在几十个不同的测试页面中，有包含同样员工信息的表，如果又有一列新数据需要添加到员工信息表中，那么在每个测试页面中都要加进去，这很糟糕。等到我们知道如何正确去做的时候，又遇到了一个更难以处理的麻烦。
【经验教训】
在前期进行工具使用的培训，之后就可以避免因工具使用不熟练而造成的巨大的时间浪费。
我们将每个能想到的测试用例都进行了自动化，包括发生几率低、影响小的边缘测试用例，并把它们都放在自动回归测试套件（test suite）里面。上述过程花费的时间并不长，但是接下来，这个测试套件要花费大量时间和主机功率（machine power）来运行，维护成本也随之提高了。所以，我们要学会慎重选择测试用例，确保它们能提供充分的测试覆盖，并只将这些测试用例放在回归测试套件中。
【小窍门】
精化回归测试套件可以在保证收益的同时降低维护费用。
正如在产品应用代码中所做的那样，我们现在不断地重复访问和重构FitNesse测试用例，以保证我们所需要的测试覆盖，同时不会过多地延长反馈周期或者花费太多时间维护测试。
【真知灼见】
经常检查自动化测试用例以保证它们是有效的。
1.4.3　使用FitNesse测试的好处
我们的FitNesse测试提供了比GUI测试套件更快的反馈，尽管比JUnit测试要慢很多。FitNesse测试套件需要60 ~ 90分钟来运行，而JUnit测试的运行时间仅仅只需要不到8分钟。像GUI测试脚本那样，我们将FitNesse测试集成到构建过程中，并且在其中运行。一开始，我们只在晚上运行这种“完全构建”（full build），但这无法提供及时的反馈，并且如果测试失败的话，我们只有在第二个晚上才能知道问题是否修复了。我们投入了更多的硬件，这样我们就可以“连续地”运行单元级别上的所有测试的完全构建。如同运行单元级别测试的构建一样，这是为了使源代码控制每接收到一次检入就能运行。大概需要90分钟运行一次，所以经常同时测试几个新的检入。