摘要: 验收测试让交付团队超越了基本的持续集成，即验证应用程序是否为用户提供了有价值的功能。不过对于刚开始尝试部署流水线的团队来说，想要自动化验收测试，需要跨过三大门槛。 一是实现和维护验收测试的技术门 ...
维护非端到端的验收测试 当团队开始编写验收测试之后，一般没过多久就会发现验收测试的开发进度越来越慢，而且有时遇到测试失败，但其实应用程序并没有缺陷的情况。验收测试对代码质量的要求也很高，相比单元测试，为了要达到测试所需的起始状态，验收测试的准备工作要更复杂。而且由于需要解析应用程序返回的数据，验收测试的断言也会更加琐碎。因此，团队最好尽早开始重构验收测试，下面的建议或许有用处： 建立最小测试数据集并且尽可能隔离测试的数据。有时团队会发现两组测试由于依赖同一批数据而产生冲突，单独执行任一组测试都能通过，但一起执行就会失败。比如在示例代码中，对于不同的货件处理事件登记场景，验收测试都会注册一个新的货件。 隐藏断言细节。这样可以减少重复代码，并提升测试的可读性。把琐碎的解析逻辑隐藏在领域语言编写的方法中。 例如：如果多个测试用例都会对货件的运输状态进行断言，可以把解析细节提取出来，这样可以去除重复代码，并且减少语法噪声。 图表 7 抽取断言 尽可能使用已实现的功能来实现测试场景的准备。有一些步骤可能是多个测试用例都需要来准备数据的，可以把此类步骤抽取出来。这样也可以减少重复的代码，当应用程序随着需求变化时，验收测试会有更强的适应性，而且抽取出来的方法由于隐藏了技术细节，使用起来更简练。直接使用数据脚本的方案看起来很诱人，但一旦内部结构改变，数据脚本也得跟着改。  图表 8 抽取公共步骤 验收测试对实践部署流水线的团队有着重要意义，也是很大的挑战。希望大家都能找到合适自己的方法。最后介绍几个有用的测试库。 Moco，当有外部系统集成需求时，集成测试和验收测试的一大利器。在示例代码中你可以找到一处例子。 GreenMail，如果应用程序需要发送邮件的话，它可以提供一臂之力。不过在部署流水线上的端到端验收测试中，由于一般应用程序和测试并不运行在同一台机器上，很难对邮件进行直接的断言。这时一种方案是修改应用程序的架构，把发送邮件的实现分离到一个专用的应用中去并使用消息队列集成。那么在验收测试中，我们就可以通过监听对应的消息队列来断言了。 Awaitility，在需要对异步处理进行断言时有所帮助。 |
