以此类推，也很容易给post和put方法添加测试。于是，在Moco的帮助下，我们就完成了对网络端点的测试。虽然这部分测试真的发起了HTTP请求，但只是针对位于localhost的Moco服务器，并且测试的内容也只是最基本的GET/POST/PUT请求，因此测试仍然快且稳定。
Moco的前世今生
在ThoughtWorks成都分公司，我们为一家保险企业开发在线应用。由于该企业的数据与核心保险业务逻辑存在于COBOL开发的后端系统中，我们所开发的在线应用都有大量集成工作。不止一个项目组发出这样的抱怨：因为依赖了被集成的远程服务，我们的测试变得缓慢而不稳定。于是，我们的一位同事郑晔开发了Moco框架，用它来简化集成点的测试。
除了我们已经看到的API模式（在测试用例中使用Moco提供的API）以外，Moco还支持standalone模式，用于快速创建一个测试用的服务器。例如下列配置（位于名为“foo.json”的文件中）就描述了一个最基本的HTTP服务器：
| [ { "response" : { "text" : "Hello, Moco" } } ] |
把这个服务器运行起来：
| java -jar moco-runner-<version>-standalone.jar -p 12306 foo.json |
再访问“http://localhost:12306”下面的任意URL，都会看到“Hello, Moco”的字样。结合各种灵活的配置，我们就可以很快地模拟出需要被集成的远程服务，用于本地的开发与功能测试。
感谢开源社区的力量，来自澳大利亚的Garrett Heel给Moco开发了一个Maven插件，让我们可以在构建过程中适时地打开和关闭Moco服务器（例如在运行Cucumber功能测试之前启动Moco服务器，运行完功能测试之后关闭），从而更好地把Moco结合到构建过程中。
目前Moco已经被ThoughtWorks成都分公司的几个项目使用，并且根据这些项目提出的需求继续演进。如果你有兴趣参与这个开源项目，不论是使用它并给它提出改进建议，还是为它贡献代码，郑晔都会非常开心。
其它组件的测试
有了针对网络端点的测试之后，其他几个组件的测试已经可以不必发起网络请求。理论上来说，每个组件都应该独自隔离进行单元测试；但个人而言，对于没有外部依赖的对象，笔者并不特别强求分别独立测试。只要有效地覆盖所有逻辑，将几个对象联合在一起测试也并无不可。
出于这样的考虑，我们可以针对整个集成点的façade（即IdentityService）进行测试。在实例化IdentityService对象时，需要mock[7]其中使用的XmlEndPoint对象，以隔离“发起网络请求”的逻辑：
| xmlEndPoint = mock(XmlEndPoint.class); identityService = new IdentityServiceImpl(xmlEndPoint); |
然后我们就需要mock的XmlEndPoint对象表现出几种不同的行为，以便测试IdentityService（及其内部使用的其他对象）在这些情况下都做出了正确的行为。以“查找用户”为例，XmlEndPoint的两种行为都是OpenPTK的文档里所描述的：
1、找到用户：HTTP状态码为“200 FOUND”，应答正文为包含用户信息的XML；
2、找不到用户：HTTP状态码为“204 NO CONTENT”，应答正文为空。
针对第一种（“找到用户”）情况，我们对mock的XmlEndPoint对象提出期望，要求它在get方法被调用时返回一个代表HTTP应答的对象，其中返回码为200、正文为包含用户信息的XML：
| when(xmlEndPoint.get(anyString())).thenReturn( new XmlEndPointResponse(STATUS_SUCCESS, userFoundResponse)); |
当mock的XmlEndPoint对象被设置为这样的行为，“查找用户”操作就应该能找到用户、并组装出合法的结果对象：
| Customer customer = identityService.findByEmail("gigix1980@gmail.com"); assertThat(customer.getFirstName(), equalTo("Jeff")); assertThat(customer.getLastName(), equalTo("Xiong")); |
