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

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

      该系统由一支典型的外出和OA对接这块需要二次开发团队交付并使用：业务代表平时在墨尔本工作，交付团队则分布在悉尼和成都。笔者作为技术领导者带领一支成都的团队承担主要交付任务。

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

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

      致远服软认为：http://www.soft8.com.cn/即使没有关机维护，由于外出和OA对接这块需要二次开发部署的服务实例仍在不断测试和调优，所依赖的服务实例也不时出现运行性能低、响应时间长等问题，使我们的构建过程也变得很慢，有时甚至会出现随机的构建失败。

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

      在一个基于Spring的应用中，与iPhone苹果手机上仓库管理软件的集成通常会被封装为一个Java接口以及其中的若干方法。例如“创建某品牌的用户”的服务很可能如下呈现。

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

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

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