Core Java

Testing with Hoverfly and Java Part 3: State

Previously we simulated a delay scenario using Hoverfly. Now it’s time to dive deeper and go for a state-based testing. By doing a stateful simulation we can change the way the tests endpoints behave based on how the state changed.

Hoverfly does have a state capability. State in a hoverfly simulation is like a map. Initially it is empty but you can define how it will get populated per request.

Our strategy would be to have a request that initializes the state and then specifies other requests that change that state.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class SimulationStateTests {
 
    private Hoverfly hoverfly;
 
    @BeforeEach
    void setUp() {
        var simulation = SimulationSource.dsl(service("http://localhost:8085")
                .get("/initialize")
                .willReturn(success("{\"initialized\":true}", "application/json")
                        .andSetState("shouldSucceed", "true")
                )
                .get("/state")
                .withState("shouldSucceed", "false")
                .willReturn(serverError().andSetState("shouldSucceed", "true"))
                .get("/state")
                .withState("shouldSucceed", "true")
                .willReturn(success("{\"username\":\"test-user\"}", "application/json")
                        .andSetState("shouldSucceed", "false"))
 
        );
 
        var localConfig = HoverflyConfig.localConfigs().disableTlsVerification().asWebServer().proxyPort(8085);
        hoverfly = new Hoverfly(localConfig, SIMULATE);
        hoverfly.start();
        hoverfly.simulate(simulation);
    }
 
    @AfterEach
    void tearDown() {
        hoverfly.close();
    }
 
}

Unfortunately on the state we can only specify values in a key value fashion and not by passing a function for a key.
However with the right workaround many scenarios could be simulated.

In the example we first initialize the state and the we issue requests that behave differently based on the state, but also they do change the state.

So we expect to have a continuous first succeed and then fail mode, which can be depicted in the following test.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@Test
    void testWithState() {
        var client = HttpClient.newHttpClient();
        var initializationRequest = HttpRequest.newBuilder()
                .uri(URI.create("http://localhost:8085/initialize"))
                .build();
        var initializationResponse = client.sendAsync(initializationRequest, HttpResponse.BodyHandlers.ofString())
                .thenApply(HttpResponse::body)
                .join();
        Assertions.assertEquals("{\"initialized\":true}", initializationResponse);
 
        var statefulRequest = HttpRequest.newBuilder()
                .uri(URI.create("http://localhost:8085/state"))
                .build();
 
        for (int i = 0; i < 100; i++) {
            var response = client.sendAsync(statefulRequest, HttpResponse.BodyHandlers.ofString())
                    .join();
 
            int statusCode = i % 2 == 0 ? 200 : 500;
 
            Assertions.assertEquals(statusCode, response.statusCode());
        }
    }

That’s all about stateful simulation. In the next part, we shall proceed with Hoverfly matchers.

Published on Java Code Geeks with permission by Emmanouil Gkatziouras, partner at our JCG program. See the original article here: Testing with Hoverfly and Java Part 3: State

Opinions expressed by Java Code Geeks contributors are their own.

Emmanouil Gkatziouras

He is a versatile software engineer with experience in a wide variety of applications/services.He is enthusiastic about new projects, embracing new technologies, and getting to know people in the field of software.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button