使用Wiremock模拟HTTP API服务

@xuemingdeng 2016-11-14T15:41:32.000000Z 字数 7705 阅读 1026

摘要：

重复创建连线测试桩是现今软件开发中存在的一个常见问题。在这篇文章里，Wojciech Bulaty为Java开发者们介绍了如何使用Wiremock框架来创建连线测试桩，避免重复发明轮子。

正文：

要点：

使用Wiremock可以极大减少创建连线测试桩所需要的时间

在JUnit里使用Wiremock可以更容易地编写各种测试用例

我们会给出一个单独使用Wiremock的例子

我们还会为手动测试人员介绍如何使用Wiremock的UI

还有其它一些内容

开场：我所知道的连线模拟工具

在我的职业生涯中，我有幸在很多大公司工作过。在工作过程中，我发现在开发上存在的一个普遍现象：开发团队总是重复开发一些相似的工具。我亲眼所见两个不同银行的开发团队在公司内部（基于不同的代码库）开发出三个以上基于HTTP的连线模拟工具（有时候也被叫作服务可视化工具）。我还在一个媒体公司看到它们同一楼层的几个团队居然开发了五个这种工具。还有一个航空企业，它开发了至少一种这样的工具。

这些基于HTTP的模拟工具主要有两方面的用途：

在自动化测试里，它们提供了可以用于创建远程虚拟服务的接口，这样就可以在CI（持续集成）环境里构建系统，比如TeamCity或Jenkins。
它们提供了Web界面，那些对技术细节不是很了解的测试人员可以在上面做一些探索性的测试。

因为同一个工具同时被用于自动化测试和手动测试，自然会有很多重叠的地方。测试人员可以使用开发人员创建的桩，这样有助于他们之间的沟通。同时这样也会减少在创建测试桩上所做的工作，相比测试人员和开发人员要分别创建自己的桩，这种方式避免了很多重复性工作。不过有些团队没有测试人员，所以他们只需要编程接口而不需要Web界面。

业界使用现成的工具

让我们从日志和数据存储方面来一窥整个行业对这些工具的使用情况。

如果有必要，你可以在一两天内轻松实现一个简单的日志框架。不过经验告诉我们，从头写一个日志框架并不是一个好主意。所以我们会使用logback、slf4j或其它一些现成的日志框架。

日志还只是个简单的问题，如果我们要考虑更复杂的数据存储，我们只能使用市场上现成的解决方案，比如Oracle、MongoDB或Neo4J，具体要根据实际需要来选择。

我们举个测试框架的例子。你不会为每个项目从头写一个测试框架，所以你会使用JUnit或者其它任何一个可用的框架，有时候可能会基于这些框架做一些定制开发。

总的来说，针对那些常见的问题，总有一些现成的解决方案。

Wiremock：一个现成的连线模拟（虚拟服务）工具

在预打包的测试框架解决方案方面，连线模拟工具（虚拟服务）会是一个更好的选择。Wiremock就是这样一个备受关注的开源框架，它使用Java编写，可以在JUnit里使用，也可以作为独立的HTTP服务运行。

在JUnit里使用Wiremock

假设我们有一个天气预报程序，它通过调用HTTP API从forecast.io获取伦敦的风速数据。预报程序获得的数据是JSON字符串，需要对它们进行解析，抽取出当前风速，再通过REST接口返回给用户。

我们现在使用JUnit编写测试用例，需要使用桩来模拟forecast.io提供的Web服务：

public class WeatherApplicationTest {
    @Rule
    public WireMockRule forecastIoService = new WireMockRule();
}

然后我们把预报程序加入到测试用例里。预报程序的start和stop方法分别放在JUnit的setup和teardown方法里。我们先测试一个正常的用例servesWindSpeedBasedOnForecastIoResponse：

public class WeatherApplicationTest {
    @Rule
    public WireMockRule forecastIoService = new WireMockRule();
    private WeatherApplication weatherApplication = new WeatherApplication();
    @Before
    public void setUp() {
        weatherApplication.start();
    }
    @After
    public void tearDown() {
        weatherApplication.stop();
    }
    @Test
    public void servesWindSpeedBasedOnForecastIoResponse(){
        // TODO
    }
}

成功的测试用例

测试过程是这样的：先发送请求到预报程序，预报程序从forecast.io获取响应数据，然后对其进行解析，加入后缀，再把它返回给用户。

首先我们使用断言检查我们想要的风速数据格式是以英里每小时（mph）为后缀的：

@Test
public void servesWindSpeedBasedOnForecastIoResponse() {
    assertEquals("12.34mph", content.toString());
}

为了得到这些数据，我们使用Apache HTTP客户端向应用程序发起请求：

@Test
public void servesWindSpeedBasedOnForecastIoResponse() throws IOException {
    Content content = Request.Get("http://localhost:" + weatherApplication.port() + "/wind-speed")
            .execute()
            .returnContent();
    assertEquals("12.34mph", content.toString());
}

现在，应用程序将向forecast.io发起获取预报数据的请求，这个时候就要使用桩来模拟真实的API：

@Test
public void servesWindSpeedBasedOnForecastIoResponse() throws IOException {  
    forecastIoService.stubFor(get(urlEqualTo(
          "/forecast/e67b0e3784104669340c3cb089412b67/51.507253,-0.127755")).willReturn(aResponse().withBody(
          "{\"currently\":{\"windSpeed\":12.34}}")
   ));
    Content content = Request.Get("http://localhost:" + 
        weatherApplication.port() + "/wind-speed")
        .execute()
        .returnContent();
    assertEquals("12.34mph", content.toString());
}

我们告诉Wiremock（forecastIoService对象）为请求“/forecast/e67b0e3784104669340c3cb089412b67/51.507253,-0.127755”创建一个桩，并把指定的json串返回。

真实的forecast.io API返回的响应数据大概是2kb，不过为了简单起见，这里只包含我们关心的字节数。这篇文章主要是为了介绍如何使用Wiremock，而不是要讨论如何做测试（TDD和测试金字塔模型）。

失败的测试用例

我们已经知道如何创建一个成功的测试用例，现在让我们看看如何创建一个失败的测试用例。我们不想在forecast.io出现问题时抛出异常，而是要把503错误码返回给用户。

这次我们仍然使用/windspeed这个URL端点和相同的forecast.io测试桩。我们创建测试桩和请求消息，它将返回一个内部错误码（HTTP 500）。我们要确保用户收到的是一个服务不可用的错误消息和错误码（HTTP 503），而不是异常的堆栈信息：

@Test
public void reportsErrorWhenForecastIoReturnsANonSuccessfulResponse()
        throws IOException {
   forecastIoService.stubFor(get(urlEqualTo("/forecast/e67b0e3784104669340c3cb089412b67/51.507253,-0.127755"))
    .willReturn(aResponse().withStatus(SC_INTERNAL_SERVER_ERROR)));
    HttpResponse httpResponse = Request.Get("http://localhost:" + weatherApplication.port() + "/wind-speed")
    .execute()
    .returnResponse();
    assertEquals(503,httpResponse.getStatusLine().getStatusCode());
    assertEquals("ERROR",IOUtils.toString(httpResponse.getEntity().getContent()));
}

这是一个非常简单的例子，不过它向我们展示了如何使用Wiremock进行成功和失败用例的自动化测试。

整个测试用例的最终代码看起来是这样的：

import com.github.tomakehurst.wiremock.junit.WireMockRule;
import org.apache.commons.io.IOUtils;
import org.apache.http.HttpResponse;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import org.junit.After;
import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;
import static com.github.tomakehurst.wiremock.client.WireMock.*;
import static 
javax.servlet.http.HttpServletResponse.SC_INTERNAL_SERVER_ERROR;
import static junit.framework.TestCase.assertEquals;
public class WeatherApplicationTest {
    @Rule
    public WireMockRule forecastIoService = new WireMockRule();
    private WeatherApplication weatherApplication = new WeatherApplication();
    @Before
    public void setUp() {
        weatherApplication.start();
    }
    @After
    public void tearDown() {
        weatherApplication.stop();
    }
@Test
public void servesWindSpeedBasedOnForecastIoResponse() throws IOException {
   forecastIoService.stubFor(get(urlEqualTo(
       "/forecast/e67b0e3784104669340c3cb089412b67/51.507253,-0.127755"))
    .willReturn(aResponse().withBody("{\"currently\":{\"windSpeed\":12.34}}"
   )));
   Content content = Request.Get("http://localhost:" + 
       weatherApplication.port() + "/wind-speed")
        .execute()
        .returnContent();
   assertEquals("12.34mph", content.toString());
}
@Test
public void reportsErrorWhenForecastIoReturnsANonSuccessfulResponse()
                                                    throws IOException {
   forecastIoService.stubFor(get(urlEqualTo(
         "/forecast/e67b0e3784104669340c3cb089412b67/51.507253,-0.127755"))
        .willReturn(aResponse().withStatus(SC_INTERNAL_SERVER_ERROR)));
   HttpResponse httpResponse = Request.Get("http://localhost:" + 
       weatherApplication.port() + "/wind-speed")
        .execute()
        .returnResponse();
        assertEquals(503, httpResponse.getStatusLine().getStatusCode());
        assertEquals("ERROR", 
               IOUtils.toString(httpResponse.getEntity().getContent()));
    }
}

上面的例子只反应了这个工具所有功能的一小方面。它的所有代码可以在我的Github主页找到，更多的细节可以查看Wiremock文档。

手动测试

在开场白部分，我们已经介绍了连线模拟工具的两个主要用途。第一个是作为自动化测试的模拟组件，这个我们已经举过例子了。接下来，我们来看看如何使用图形化Web控制台界面做手动测试。

Wiremock的控制台

Wiremock可以通过命令行来调用，也可以通过Postman或cURL这样的工具来做设置操作。可以往指定的URL发送一个HTTP POST请求来新建一个桩，比如往http://:/__admin/mappings/new发送请求

{
    "request": {
        "method": "GET",
        "url": "/some/thing"
    },
    "response": {
        "status": 200,
        "body": "Hello world!",
        "headers": {
            "Content-Type": "text/plain"
        }
    }
}

，这个就相当于在Java里执行了以下代码：

stubFor(get(urlEqualTo("/some/thing"))
            .willReturn(aResponse()
                .withHeader("Content-Type", "text/plain")
                .withBody("Hello world!")));

解决手动测试的问题

如果你的测试人员对技术细节不是很了解或者他们不希望花太多时间在技术细节上，那你可以帮助他们把精力集中在他们擅长的手动测试上。

首先，可以基于Wiremock开发一个Web界面或Swing图形界面。经验告诉我，这样可能需要1到10个开发人员花费最多12个月的时间。

还有一种选择，就是使用现成的产品，比如专门为敏捷团队打造的Traffic Parrot。Traffic Parrot是一款带有Web界面的连线模拟工具，一般敏捷开发团队会用到它。开发人员可以使用Wiremock创建测试用例，再把它们的定义导出到Traffic Parrot。测试人员可以使用Traffic Parrot的Web 界面为手动测试创建测试桩。因为工作原因，我曾经在多个公司使用这个工具，现在我收集了一些常用的场景，并把它们共享出来。也许它们可以为大家节省一些时间，避免那些我曾经犯过的错误。

模拟场景

在我的咨询顾问职业生涯中，我遇到了另一类有关虚拟服务的问题，就是经常出现一个用例需要用到多个端点或需要返回多种响应的情况。例如，如果你要为用户提供基于位置的当前风速数据，需要调用两个Web服务，一个用于获取GPS坐标信息，另一个用于获取天气预报数据。在JUnit里看起来是这样的：

gpsService.stubFor(get(urlEqualTo("/what-are-my-coordinates"))
   .willReturn(aResponse().withBody("12.34,-0.12")));        
weatherService.stubFor(get(urlEqualTo("/forecast/12.34,-0.12"))
   .willReturn(aResponse().withBody("{\"currently\":{\"windSpeed\":3.55}}")));

在这个用例里，测试人员希望在Web界面上看到已经计算好的地理坐标和相应的预报结果下拉列表。这样，在切换地理坐标时可以直接得到相应的预报结果，而不需要再次发出请求。

Traffic Parrot已经包含了这个功能，所以可以直接使用。

其它工具

如果你想在选定一个工具之前先挑挑拣拣，那么你真的有很多选择。除了Wiremock之外，我所知道的还有超过40个这种类型的工具，它们使用不同的语言编写，运行在不同的平台上，提供各种不同的功能。
这里例举几个：

Mountebank（可用于Java、Python、C#、Clojure等语言平台）
VCR（在Ruby和Ruby on Rails平台很受欢迎）
Stubby4j（基于Java，提供了另一种设计API的方式）

不过基于Java的Wiremock仍然是目前最流行的，它在Github上有1400多个关注和40多个贡献者。

更多信息

作为这篇文章的补充阅读，Christopher Batey在他的文章“构建容错性微服务的六大原则”里介绍了他使用Wiremock的几种场景，包括连接丢失、连接变慢及其它场景。

下一步

更多地了解Wiremock
观看我的关于如何为敏捷团队创建工具的视频，这个视频把我5年的经验浓缩在了18分钟的时间里
更多地了解Traffic Parrot

关于作者

此处输入图片的描述 Wojciech Bulaty是WB软件咨询公司的高级软件工程师。他通过写作分享了很多他在敏捷、自动化、极限编程、TDD、BDD、结对编程和代码清理等方面的经验。WB软件咨询公司为British Sky Broadcasting、Lloyds Bank以及很多初创公司做过咨询。他们最近发布了Traffic Parrot，一款用于创建虚拟服务的软件工具。

查看英文原文：How Java developers can use the Wiremock framework to simulate HTTP-based APIs

使用Wiremock模拟HTTP API服务

内容目录