企业系统集成点测试策略

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

背景

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

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

痛点

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

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

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

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

如何测试集成点

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

public interface IdentityService {Customer create（Brand brand, Customer customer）;

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

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

用面向对象的语言来集成一个基于HTTP的服务，集成点的设计经常会出现这样一个模式，其中涉及五个主要的组成部分：门面（Facade）；请求构造器（Request Builder）；请求路由器（Request Router）；网络端点（Network End Point）；应答解析器（Response Parser）。它们之间的交互关系如下图：