Wiremock: réponses multiples pour la même URL et le même contenu?

Question

En outre partagé ici: https://github.com/tomakehurst/wiremock/issues/625

J'écris un test d'intégration pour vérifier que mon application qui interagit avec une API REST traite les demandes infructueuses de façon appropriée. Pour ce faire, je souhaite simuler un scénario dans lequel une requête GET est effectuée deux fois sur un point de terminaison HTTP. La première fois, la demande échoue avec un code d'état de réponse de 500; deuxième fois, la demande est réussie avec un code d'état de réponse de 200. Prenons l'exemple ci-dessous:

@Rule 
public WireMockRule wireMockRule = new WireMockRule(wireMockConfig().dynamicPort() 
                   .dynamicHttpsPort()); 

@Test 
public void testRetryScenario(){ 

// First StubMapping 
stubFor(get(urlEqualTo("/my/resource")) 
     .withHeader("Accept", equalTo("text/xml")) 
     .willReturn(aResponse() 
      .withStatus(500) // request unsuccessful with status code 500 
      .withHeader("Content-Type", "text/xml") 
      .withBody("<response>Some content</response>"))); 

// Second StubMapping 
stubFor(get(urlEqualTo("/my/resource")) 
     .withHeader("Accept", equalTo("text/xml")) 
     .willReturn(aResponse() 
      .withStatus(200) // request successful with status code 200 
      .withHeader("Content-Type", "text/xml") 
      .withBody("<response>Some content</response>"))); 

//Method under test that makes calls to endpoint 
doSomething(); 

Thread.sleep(5000); 

//Verify GET request was made again after first attempt 
verify(exactly(2), getRequestedFor(urlEqualTo("/my/resource"))); 

} 

Y at-il un moyen d'éviter la 2e StubMapping de substitution de la première - pour faire en sorte que la première fois doSomething() marques une demande, une réponse avec le code d'état 500 est retourné, et la deuxième fois, une réponse différente avec le code d'état 200 est retourné?

Answer 1

Voici à quoi sert la fonction Scénarios. Vous devrez placer les deux stubs dans un scénario (c'est-à-dire le même nom de scénario), faire passer le premier stub trigger à un nouvel état, puis rendre le second stub subordonné au scénario étant dans le second état et le premier membre subordonné sur le scénario étant dans l'état STARTED.

Voir: http://wiremock.org/docs/stateful-behaviour/

Answer 2

Quelque chose comme cela a contribué, en utilisant les scénarios disposent

// First StubMapping 
stubFor(get(urlEqualTo("/my/resource")) 
     .withHeader("Accept", equalTo("text/xml")) 
     .inScenario("Retry Scenario") 
     .whenScenarioStateIs(STARTED) 
     .willReturn(aResponse() 
      .withStatus(500) // request unsuccessful with status code 500 
      .withHeader("Content-Type", "text/xml") 
      .withBody("<response>Some content</response>")) 
     .willSetStateTo("Cause Success"));); 

// Second StubMapping 
stubFor(get(urlEqualTo("/my/resource")) 
     .withHeader("Accept", equalTo("text/xml")) 
     .inScenario("Retry Scenario") 
     .whenScenarioStateIs("Cause Success") 
     .willReturn(aResponse() 
      .withStatus(200) // request successful with status code 200 
      .withHeader("Content-Type", "text/xml") 
      .withBody("<response>Some content</response>")));