![集成学习](https://i-blog.csdnimg.cn/blog_migrate/af0acdc39189497d0ce0b66dbeb92a76.png)
集成学习
无论您是遵循传统的测试金字塔还是采用诸如“测试蜂窝”这样的较新方法,都应该在开发过程中的某个时候开始编写集成测试。您可以编写不同类型的集成测试。 从持久性测试开始,您可以检查组件之间的交互,也可以模拟调用外部服务。 本文将讨论后一种情况。在谈论WireMock之前,让我们从一个激励性的例子开始。
ChuckNorrisFact服务
完整的示例可以在GitHub上找到。在以前的博客文章中,您可能已经看到我使用Chuck Norris事实API 。 该API将作为我们实现所依赖的另一项服务的示例。我们有一个简单的ChuckNorrisFactController
作为用于手动测试的API。 旁边的“业务”类存在ChuckNorrisService
,做调用外部API。 它使用Spring的RestTemplate
。 没什么特别的。我多次看到的是模拟RestTemplate并返回一些预先确定的答案的测试。 该实现可能如下所示:
@Service
public class ChuckNorrisService{
...
public ChuckNorrisFact retrieveFact() {
ResponseEntity<ChuckNorrisFactResponse> response = restTemplate.getForEntity(url, ChuckNorrisFactResponse. class );
return Optional.ofNullable(response.getBody()).map(ChuckNorrisFactResponse::getFact).orElse(BACKUP_FACT);
}
...
}
在检查成功案例的常规单元测试旁边,将至少有一项覆盖错误案例的测试,即4xx或5xx状态代码:
@Test
public void shouldReturnBackupFactInCaseOfError() {
String url = " http://localhost:8080 " ;
RestTemplate mockTemplate = mock(RestTemplate. class );
ResponseEntity<ChuckNorrisFactResponse> responseEntity = new ResponseEntity<>(HttpStatus.SERVICE_UNAVAILABLE);
when(mockTemplate.getForEntity(url, ChuckNorrisFactResponse. class )).thenReturn(responseEntity);
var service = new ChuckNorrisService(mockTemplate, url);
ChuckNorrisFact retrieved = service.retrieveFact();
assertThat(retrieved).isEqualTo(ChuckNorrisService.BACKUP_FACT);
}
看起来还不错吧? 响应实体返回503错误代码,我们的服务不会崩溃。 所有测试都是绿色的,我们可以部署我们的应用程序。不幸的是,Spring的RestTemplate不能像这样工作。 getForEntity
的方法签名为我们提供了一个非常小的提示。 它指出throws RestClientException
。 这就是模拟的RestTemplate与实际实现不同的地方。 我们将永远不会收到状态码为4xx或5xx的ResponseEntity
。 RestTemplate将抛出一个子类RestClientException
。 通过查看类的层次结构,我们可以对可能抛出的结果有一个很好的印象:
因此,让我们看看如何使这个测试更好。
WireMock进行救援
WireMock通过启动模拟服务器并返回将其配置为返回的答案来模拟Web服务。 得益于出色的DSL,它很容易集成到测试中,并且模拟请求也很简单。对于JUnit 4,有一个WireMockRule
可以帮助启动停止服务器。 对于JUnit 5,您必须自己做。 当您检查示例项目时,可以找到ChuckNorrisServiceIntegrationTest
。 这是基于JUnit 4的SpringBoot测试。让我们来看一下。最重要的部分是ClassRule
:
@ClassRule
public static WireMockRule wireMockRule = new WireMockRule();
如前所述,这将启动和停止WireMock服务器。 您也可以使用该规则作为常规Rule
来为每个测试启动和停止服务器。 对于我们的测试,这不是必需的。接下来,您可以看到几种configureWireMockFor...
方法。 这些包含WireMock何时返回答案的说明。 将WireMock配置分为几种方法并从测试中调用它们是我使用WireMock的方法。 当然,您可以在@Before
方法中设置所有可能的请求。 对于成功案例,我们这样做:
public void configureWireMockForOkResponse(ChuckNorrisFact fact) JsonProcessingException { configureWireMockForOkResponse(ChuckNorrisFact fact) throws JsonProcessingException {
ChuckNorrisFactResponse chuckNorrisFactResponse = new ChuckNorrisFactResponse chuckNorrisFactResponse = ChuckNorrisFactResponse( "success" , fact);
stubFor(get(urlEqualTo( "/jokes/random" ))
.willReturn(okJson(OBJECT_MAPPER.writeValueAsString(chuckNorrisFactResponse))));
}
所有方法都是从com.github.tomakehurst.wiremock.client.WireMock
静态com.github.tomakehurst.wiremock.client.WireMock
。 如您所见,我们将HTTP GET存入路径/jokes/random
并返回一个JSON对象。 的okJson()
方法只是JSON内容的200个响应的简写。 对于错误情况,代码甚至更简单:
private void configureWireMockForErrorResponse() {
stubFor(get(urlEqualTo( "/jokes/random" ))
.willReturn(serverError()));
}
如您所见,DSL使阅读说明变得容易。将WireMock放置在适当的位置,我们可以看到我们先前的实现不起作用,因为RestTemplate引发了异常。 因此,我们必须调整代码:
public ChuckNorrisFact retrieveFact() {
try {
ResponseEntity<ChuckNorrisFactResponse> response = restTemplate.getForEntity(url, ChuckNorrisFactResponse. class );
return Optional.ofNullable(response.getBody()).map(ChuckNorrisFactResponse::getFact).orElse(BACKUP_FACT);
} catch (HttpStatusCodeException e){
return BACKUP_FACT;
}
}
这已经涵盖了WireMock的基本用例。 配置请求的答案,执行测试,检查结果。 就这么简单。尽管如此,在云环境中运行测试时通常会遇到一个问题。 让我们看看我们能做什么。
动态端口上的WireMock
您可能已经注意到,项目中的集成测试包含一个ApplicationContextInitializer
类及其@TestPropertySource
批注将覆盖实际API的URL。 那是因为我想在随机端口上启动WireMock。 当然,您可以为WireMock配置一个固定端口,并在测试中将此端口用作硬编码值。 但是,如果您的测试在某些云提供商的基础架构上运行,则无法确定端口是否可用。 因此,我认为随机端口更好。不过,在Spring应用程序中使用属性时,我们必须以某种方式将随机端口传递给我们的服务。 或者,如您在示例中看到的那样,覆盖URL。 这就是为什么我们使用ApplicationContextInitializer
。 我们将动态分配的端口添加到应用程序上下文中,然后可以使用属性来引用它${wiremock.port}
。 这里唯一的缺点是我们现在必须使用ClassRule。 否则,我们无法在初始化Spring应用程序之前访问端口。解决了此问题后,让我们看一下涉及HTTP调用的一个常见问题。
超时时间
WireMock提供了更多的响应可能性,而不仅仅是对GET请求的简单答复。 经常被遗忘的另一个测试案例是测试超时。 开发人员往往会忘记在RestTemplate
甚至URLConnections
上设置超时。 如果没有超时,则两者都将等待无限量的时间进行响应。 在最好的情况下,您不会注意到,在最坏的情况下,所有线程都将等待永远不会到达的响应。因此,我们应该添加一个模拟超时的测试。 当然,我们也可以使用Mockito模拟来创建延迟,但是在这种情况下,我们将再次猜测RestTemplate的行为。 使用WireMock模拟延迟非常简单:
private void configureWireMockForSlowResponse() throws JsonProcessingException {
ChuckNorrisFactResponse chuckNorrisFactResponse = new ChuckNorrisFactResponse chuckNorrisFactResponse = ChuckNorrisFactResponse( "success" , new ChuckNorrisFact(1L, "" ));
stubFor(get(urlEqualTo( "/jokes/random" ))
.willReturn(
okJson(OBJECT_MAPPER.writeValueAsString(chuckNorrisFactResponse))
.withFixedDelay(( int ) Duration.ofSeconds(10L).toMillis())));
}
withFixedDelay()
需要一个表示毫秒的int值。 我更喜欢使用Duration或至少一个表示该参数表示毫秒的常量,而不必每次都读取JavaDoc。在RestTemplate
上设置超时并添加响应缓慢的测试后,我们可以看到RestTemplate抛出ResourceAccessException
。 因此,我们可以调整catch块以捕获此异常和HttpStatusCodeException
也可以仅捕获两者的超类:
public ChuckNorrisFact retrieveFact() {
try {
ResponseEntity<ChuckNorrisFactResponse> response = restTemplate.getForEntity(url, ChuckNorrisFactResponse. class );
return Optional.ofNullable(response.getBody()).map(ChuckNorrisFactResponse::getFact).orElse(BACKUP_FACT);
} catch (RestClientException e){
return BACKUP_FACT;
}
}
现在,我们已经很好地介绍了执行HTTP请求时最常见的情况,并且可以确定我们正在测试接近真实条件的条件。
为什么不飞翔?
HTTP集成测试的另一个选择是Hoverfly 。 它的工作原理类似于WireMock,但我更喜欢后者。 原因是在运行包含浏览器的端到端测试时,WireMock也非常有用。 Hoverfly(至少是Java库)受JVM代理的限制。 这可能使它比WireMock更快,但是当例如某些JavaScript代码开始起作用时,它根本不起作用。 当您的浏览器代码也直接调用某些其他服务时,WireMock启动Web服务器这一事实非常有用。 然后,您也可以使用WireMock来模拟它们,并编写例如Selenium测试。
结论
我希望本文可以向您展示两件事:
- 集成测试的重要性
- WireMock非常好
当然,这两个主题都可以填满更多文章。 尽管如此,我还是想让您了解如何使用WireMock及其功能。 随时检查他们的文档,然后尝试更多其他事情。 例如,也可以使用WireMock测试身份验证。
翻译自: https://www.javacodegeeks.com/2019/11/better-integration-tests-with-wiremock.html
集成学习