这正是我们面对的情况，也正是“网络端点”这个概念应该出现的时候。使用抽取函数和抽取类（Extract Class）的重构手法，我们就能得到名为SOAPEndPoint的类：
| public class SOAPEndPoint { public String post(String soapAction, String requestBody) { PostMethod postMethod = getPostMethod(soapAction, requestBody); new HttpClient().executeMethod(postMethod); String responseBody = postMethod.getResponseBodyAsString(); if (responseBodyAsString.contains("faultstring")) { throw new WmbException(); } return responseBody; } |
原来的代码变为使用这个新的类：
| // 1. prepare request body String requestBody = renderTemplate(velocityContext, templateName); // 2. execute a post method and get back response body // soapEndPoint is dependency injected by Spring Framework String responseBody = soapEndPoint.post(soapAction, requestBody); // 3. deal with response body Document document = parseResponse(responseBody); return document; |
再按照前文所述的测试策略，使用Moco给SOAPEndPoint类添加测试。可以看到，SOAPEndPoint的逻辑相当简单：把指定的请求文本POST到指定的URL；如果应答文本包含“faultstring”字符串，则抛出异常；否则直接返回应答文本。尽管名为“SOAPEndPoint”，post这个方法其实根本不关心请求与应答是否符合SOAP协议，因此在测试这个方法时我们也不需要让Moco返回符合SOAP协议的应答文本，只要覆盖应答中是否包含“faultstring”字符串的两种情况即可。
读者或许会问：既然post方法并不介意请求与应答正文是否符合SOAP协议，为什么这个类叫SOAPEndPoint？答案是：在本文没有给出实现代码的getPostMethod方法中，我们需要填入一些HTTP头信息，这些信息是与提供Web Services的被集成服务相关的。这些HTTP头信息（例如应用程序的身份认证、Content-Type等）适用于所有服务方法，因此可以抽取到通用的getPostMethod方法中。
随后，我们可以编写一些描述性的集成测试，并用mock的方式使所有“使用SOAPEndPoint的类”的测试不再发起网络请求。至此，我们就完成了对已有的集成点的重构，并得到了一组符合前文所述的测试策略的测试用例。当然读者可以继续重构，将请求构造器与应答解析器也分离出来，在此不再赘述。
小结
在开发一个“重集成”的JavaEE Web应用的过程中，自动化测试中对被集成服务的依赖使得构建过程变得缓慢而脆弱。通过对集成点实现的考察，我们识别出一个典型的集成点设计模式。基于此模式以及与之对应的测试策略，借助Moco这个测试工具，我们能够很好地隔离对被集成服务的依赖，使构建过程快速而可靠。
随后我们还考察了已有的集成点实现，并将其重构成为前文所述的结构，从而将同样的测试策略应用于其上。通过这个过程，我们验证了：本文所述的测试策略是普遍适用的，遗留系统同样可以通过文中的重构过程达到解耦实现、从而分层测试的目标。
