接下来，当运行测试时，你可以得到一份漂亮的html报告

图表 6 测试运行入口

维护非端到端的验收测试

　　当团队开始编写验收测试之后，一般没过多久会发现验收测试的开发进度越来越慢，而且有时遇到测试失败，但其实应用程序并没有缺陷的情况。验收测试对代码质量的要求也很高，相比单元测试，为了要达到测试所需的起始状态，验收测试的准备工作要更复杂。而且由于需要解析应用程序返回的数据，验收测试的断言也会更加琐碎。因此，团队好尽早开始重构验收测试，下面的建议或许有用处：

　　建立小测试数据集并且尽可能隔离测试的数据。有时团队会发现两组测试由于依赖同一批数据而产生冲突，单独执行任一组测试都能通过，但一起执行会失败。比如在示例代码中，对于不同的货件处理事件登记场景，验收测试都会注册一个新的货件。

　　隐藏断言细节。这样可以减少重复代码，并提升测试的可读性。把琐碎的解析逻辑隐藏在领域语言编写的方法中。例如：如果多个测试用例都会对货件的运输状态进行断言，可以把解析细节提取出来，这样可以去除重复代码，并且减少语法噪声。

图表 7 抽取断言

　　尽可能使用已实现的功能来实现测试场景的准备。有一些步骤可能是多个测试用例都需要来准备数据的，可以把此类步骤抽取出来。这样也可以减少重复的代码，当应用程序随着需求变化时，验收测试会有更强的适应性，而且抽取出来的方法由于隐藏了技术细节，使用起来更简练。直接使用数据脚本的方案看起来很诱人，但一旦内部结构改变，数据脚本也得跟着改。