Testing REST APIs With Hoverfly

Hoverfly is an open-source API simulation tool for automated tests. It is written in Go but also has native support for Java and can be run inside JUnit test. Hoverfly can be used for testing REST APIs but can also be useful for testing calls between microservices. We have two running modes available: simulating and capturing. In simulating mode, we just simulate interaction with other services by creating response sources. In capturing mode, requests will be made to the real service as normal, only they will be intercepted and recorded by Hoverfly.

In one of my previous articles (Testing Java Microservices), I described the competitive tool for testing — Spring Cloud Contract. In the article about Hoverfly, I will use the same sample application based on Spring Boot, which I created for the needs of that previous article. The source code is available on GitHub in the Hoverfly branch. We have some microservices that interact with each other. Based on this sample, I’m going to show how to use Hoverfly for component testing.

To enable testing with Hoverfly, we have to include the following dependency in pom.xml file.

<dependency>
    <groupId>io.specto</groupId>
    <artifactId>hoverfly-java</artifactId>
    <version>0.8.0</version>
    <scope>test</scope>
</dependency>

Hoverfly can be easily integrated with JUnit. We can orchestrate it using JUnit @ClassRule. Like I mentioned before, we can switch between two different modes. In the code fragment below, I decided to use mixed-strategy inCaptureOrSimulationMode, where Hoverfly Rule is started in capture mode if the simulation file does not exist and in simulate mode if the file does exist. The default location of output JSON file is src/test/resources/hoverfly. By calling printSimulationData on HoverflyRule , we are printing all simulation data on the console.

@RunWith(SpringRunner.class)
@SpringBootTest(classes = { Application.class }, webEnvironment = WebEnvironment.DEFINED_PORT)
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class AccountApiFullTest {
 
    protected Logger logger = Logger.getLogger(AccountApiFullTest.class.getName());
 
    @Autowired
    TestRestTemplate template;
 
    @ClassRule
    public static HoverflyRule hoverflyRule = HoverflyRule
            .inCaptureOrSimulationMode("account.json", HoverflyConfig.configs().proxyLocalHost()).printSimulationData();
 
    @Test
    public void addAccountTest() {
        Account a = new Account("1234567890", 1000, "1");
        ResponseEntity<Account> r = template.postForEntity("/accounts", a, Account.class);
        Assert.assertNotNull(r.getBody().getId());
        logger.info("New account: " + r.getBody().getId());
    }
 
    @Test
    public void findAccountByNumberTest() {
        Account a = template.getForObject("/accounts/number/{number}", Account.class, "1234567890");
        Assert.assertNotNull(a);
        logger.info("Found account: " + a.getId());
    }
 
    @Test
    public void findAccountByCustomerTest() {
        Account[] a = template.getForObject("/accounts/customer/{customer}", Account[].class, "1");
        Assert.assertTrue(a.length > 0);
        logger.info("Found accounts: " + a);
    }
 
}

Now, let’s run our JUnit test class twice. During first attempt all requests are forwarded to the Spring @RestController which connects to embedded Mongo database. At the same time all requests and responses are recorded by Hoverfly and saved in the account.json file. This file fragment is visible below. During the second attempt all data is loaded from source file, there is no interaction with AccountController.

"request" : {
  "path" : {
    "exactMatch" : "/accounts/number/1234567890"
  },
  "method" : {
    "exactMatch" : "GET"
  },
  "destination" : {
    "exactMatch" : "localhost:2222"
  },
  "scheme" : {
    "exactMatch" : "http"
  },
  "query" : {
    "exactMatch" : ""
  },
  "body" : {
    "exactMatch" : ""
  }
},
"response" : {
  "status" : 200,
  "body" : "{\"id\":\"5980642bc96045216447023b\",\"number\":\"1234567890\",\"balance\":1000,\"customerId\":\"1\"}",
  "encodedBody" : false,
  "templated" : false,
  "headers" : {
    "Content-Type" : [ "application/json;charset=UTF-8" ],
    "Date" : [ "Tue, 01 Aug 2017 11:21:15 GMT" ],
    "Hoverfly" : [ "Was-Here" ]
  }
}

Now, let’s take a look at the customer-service tests. Inside GET /customer/{id} , we are invoking method GET /accounts/customer/{customerId} from account-service . This method is simulating by Hoverfly with success response, as you can see below.

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.DEFINED_PORT)
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class CustomerControllerTest {
 
    @Autowired
    TestRestTemplate template;
 
    @ClassRule
    public static HoverflyRule hoverflyRule = HoverflyRule
            .inSimulationMode(dsl(service("account-service:2222").get(startsWith("/accounts/customer/"))
                    .willReturn(success("[{\"id\":\"1\",\"number\":\"1234567890\"}]", "application/json"))))
            .printSimulationData();
 
    @Test
    public void addCustomerTest() {
        Customer c = new Customer("1234567890", "Jan Testowy", CustomerType.INDIVIDUAL);
        c = template.postForObject("/customers", c, Customer.class);
    }
 
    @Test
    public void findCustomerWithAccounts() {
        Customer c = template.getForObject("/customers/pesel/{pesel}", Customer.class, "1234567890");
        Customer cc = template.getForObject("/customers/{id}", Customer.class, c.getId());
        Assert.assertTrue(cc.getAccounts().size() > 0);
    }
}

To run this test successfully, we should override some properties from application.yml in src/test/resources/application.yml. Eureka discovery from Ribbon client should be disabled and the same for Hystrix in @FeignClient. The ribbon listOfServers property should have the same value as service address inside HoverflyRule.

eureka:
  client:
    enabled: false
 
ribbon:
  eureka:
    enable: false
  listOfServers: account-service:2222
 
feign:
  hystrix:
    enabled: false

Here’s @FeignClient implementation for invoking API method from account-service.

@FeignClient("account-service")
public interface AccountClient {
 
    @RequestMapping(method = RequestMethod.GET, value = "/accounts/customer/{customerId}", consumes = {MediaType.APPLICATION_JSON_VALUE})
    List<Account> getAccounts(@PathVariable("customerId") String customerId);
 
}

When using simulation mode there is no need to start @SpringBootTest. Hoverfly has also some interesting capabilities like response templating, for example basing on path parameter, like in the fragment below.

public class AccountApiTest {
 
    TestRestTemplate template = new TestRestTemplate();
 
    @ClassRule
    public static HoverflyRule hoverflyRule = HoverflyRule.inSimulationMode(dsl(service("http://account-service")
            .post("/accounts").anyBody().willReturn(success("{\"id\":\"1\"}", "application/json"))
            .get(startsWith("/accounts/")).willReturn(success("{\"id\":\"{{Request.Path.[1]}}\",\"number\":\"123456789\"}", "application/json"))));
 
    @Test
    public void addAccountTest() {
        Account a = new Account("1234567890", 1000, "1");
        ResponseEntity<Account> r = template.postForEntity("http://account-service/accounts", a, Account.class);
        System.out.println(r.getBody().getId());
    }
 
    @Test
    public void findAccountByIdTest() {
        Account a = template.getForObject("http://account-service/accounts/{id}", Account.class, new Random().nextInt(10));
        Assert.assertNotNull(a.getId());
    }
 
}

We can simulate fixed method delay using DSL. The delay be set for all requests or for a particular HTTP method. Our delayed @ClassRule for CustomerControllerTest will now look like in the fragment below.

@ClassRule
public static HoverflyRule hoverflyRule = HoverflyRule
        .inSimulationMode(dsl(service("account-service:2222").andDelay(3000, TimeUnit.MILLISECONDS).forMethod("GET").get(startsWith("/accounts/customer/"))
        .willReturn(success("[{\"id\":\"1\",\"number\":\"1234567890\"}]", "application/json"))));

And now, you can add the ReadTimeout property into your Ribbon client configuration and run JUnit test again. You should receive the following exception: java.net.SocketTimeoutException: Read timed out

ribbon:
  eureka:
    enable: false
  ReadTimeout: 1000
  listOfServers: account-service:2222