企业系统集成点测试策略

第第页企业系统集成点测试策略企业系统集成点测试策略

发表于：2023-08-29来源：InfoQ：熊节点击数：标签：集成测试

集成是企业应用系统中绕不开的话题。与外部系统的集成点不仅实现起来麻烦，更是难以测试。本文介绍了一种普遍适用的集成点测试策略，兼顾测试的覆盖程度、速度、可靠性和可重复性，为集成点的实现与测试建立一个通用的参考。

集成是企业应用系统中绕不开的话题。与外部系统的集成点不仅实现起来麻烦，更是难以（测试）。本文介绍了一种普遍适用的集成点（测试）策略，兼顾测试的覆盖程度、速度、可靠性和可重复性，为集成点的实现与测试建立一个通用的参考。

背景

本文作为例子介绍的系统是一个典型的（Java）EE（Web）应用，基于（Java）6和Spring（开发），采用Maven构建。该系统需要以XMLoverHTTP的方式集成两个外部系统。

该系统由一支典型的分布式团队交付：业务代表平常在墨尔本工作，交付团队则分布在悉尼和成都。笔者作为技术领导者带领一支成都的团队承担主要交付任务。

痛点

由于需要集成两个外部系统，我们的Maven构建[1]过程中有一部分测试(使用JUnit)是与集成相关的。这部分测试给构建过程造成了一些麻烦。

首先是依赖系统的可靠性问题。在被依赖的两个服务之中，有一个服务部署在开发环境中的实例经常会关机维护，而它一旦关机就会导致与其集成的测试无法通过，进而导致整个构建失败。我们的交付团队严格遵守持续集成实践：构建失败时不允许提交代码。这么一来，当我们依赖的服务关机维护时，交付团队正常的工作节奏就会被打乱。

即使没有关机维护，由于开发环境中部署的服务实例仍在不断测试和调优，被依赖的服务实例也不时出现运行（性能）低、响应时间长等问题，使我们的构建过程也变得很慢，有时甚至会出现随机的构建失败。

被依赖的服务在开发环境下不可靠、性能低，会使应用程序的构建过程也随之变得脆弱而缓慢，从而打击程序员频繁进行构建的积极性，甚至损害持续集成的有效性。作为团队的技术领导者，我希望解决这个问题，使构建可靠而快速地运行，以确保所有人都愿意频繁执行构建。

如何测试集成点

在一个基于Spring的应用中，与外部服务的集成通常会被封装为一个Java接口以及其中的若干方法。例如"创建某品牌的用户'的服务很可能如下呈现：

publicinterfaceIdentityService{Customercreate(Brandbrand,Customercustomer);

一个实现了IdentityService接口的对象会被Spring实例化并放入应用上下文，需要使用该服务的客户代码可以通过依赖注入获得该对象的引用，从而调用它的create方法。在测试这些客户代码时，始终可以mock一个IdentityService对象，将其注入被测对象，从而解耦对外部服务的依赖。这是使用依赖注入带来的收益。

因此，我们的问题主要聚焦于集成点本身的测试。

用面向对象的语言来集成一个基于HTTP的服务，集成点的设计经常会出现这样一个模式，其中涉及五个主要的组成部分：门面(Faade);请求构造器(RequestBuilder);请求路由器(RequestRouter);网络端点(NetworkEndPoint);应答解析器(ResponseParser)。它们之间的交互关系如下图：

显而易见，在这个模式中，真正需要发出网络请求的只有网络端点这个组件。该组件的作用即是"按照预先规定好的通信方式，向给定的网络地址发出给定的请求，返回应答内容'。对于基于HTTP的服务集成而言，网络端点的接口大致如下呈现：

publicinterfaceEndPoint{Responseget(Stringurl);Responsepost(Stringurl,StringrequestBody);Responseput(Stringurl,StringrequestBody);

其中Response类包含两项主要信息：HTTP返回码，以及应答正文。

publicclassResponse{privatefinalintstatusCode;privatefinalStringresponseBody;

不难注意到，EndPoint类所关心的是把正确的请求发送到正确的地址、取回正确的应答。它并不关心这个地址究竟是什么(这是请求路由器组件的责任)，也不关心请求与应答包含什么信息(这是请求构造器和应答解析器的责任)。这一特点使得EndPoint类的测试完全不需要依赖真实服务的存在。

网络端点的测试

如前所述，EndPoint类并不关心发送请求的地址，也不关心请求与应答的内容，只关心以正确的方式来发送请求并拿回应答"正确的方式'可能包括身份认证与授权、必要的HTTP头信息等。为了测试这样一个类，我们不需要朝真正的网络服务地址发送请求，也不需要遵循真实的请求/应答协议，完全可以自己创造一个HTTP服务，用最简单的请求/应答文本来进行测试。

Moco[2]就是专门用于这种场合的（测试工具）。按照的介绍，Moco是"一个非常容易设置的stub框架，主要用于测试与集成'。在JUnit测试中，只需要两行代码就可以声明一个HTTP（服务器），该（服务器）监听12306端口，对一切请求都会以字符串"foo'作为应答：

MocoHttpServerserver=httpserver(12306);server.reponse(foo);

接下来就可以像访问正常的服务器一样，用ApacheCommonsHTTPClient来访问这个服务器。唯一需要注意的是，访问服务器的代码需要放在running块中，以确保服务器能被正常关闭：

running(server,newRunnable(){

@Override

publicvoidrun()throwsIOException{

Contentcontent=Request.Get(http://localhost:12306).execute().returnContent();

assertThat(content.asString(),is(foo));

}

}

当然，作为一个测试辅助工具，Moco支持很多灵活的配置，感兴趣的读者可以自行查阅文档。接下来我们就来看如何用Moco来测试我们系统中的网络端点组件。作为例子，我们这里需要集成的是用于管理用户身份信息的OpenPTK[3]。OpenPTK使用自定义的XML通信协议，并且