Software Design

Tests are an essential part of our codebase. At the very least, they minimize the risk of regression when we modify our code. There are several types of tests, and each has a specific role: unit tests, integration tests, component tests, contract tests and end-to-end tests. Therefore, it is crucial to understand the role of each type of test to leverage its potential.

This article describes a strategy to use them to test Java Spring Boot microservices. It presents each type of test’s role, scope, and tooling.

Component tests allow testing complete use cases from end to end. However, they are often expensive, especially in terms of setup and execution time. Thus, thought needs to be given to defining their scope. Nevertheless, they are required to check and document the overall behaviour of the application or the microservice.

I have noticed that, in the context of microservices, these tests are cost-effective. Indeed, they can be easy to set up as it is often possible to use the already existing external API of the microservice without needing additional elements (like a fake server, for instance). Moreover, the scope of a microservice is generally limited and can be tested exhaustively in isolation.

This article aims to show how to make these tests robust. The main idea is to make them independent of the implementation.

In a microservices architecture, several things could go wrong. For example, a middleware, the network or the service you want to contact could be down. In this world of uncertainty, you have to anticipate problems to avoid breaking the entire chain and throwing an error to the end-user when you could offer a partially degraded service instead.

This article aims to show how to implement the circuit breaker pattern using Hystrix, Feign Client and Spring Boot.

I often encounter pieces of code that look like this:

public class Day {
  public void start(Weather weather) {
    switch(weather) {
      case RAINY:
          takeAnUmbrella();
          break;
      case SUNNY:
          takeAHat();
          break;
      case STORMY:
          stayHome();
          break;
      default:
          doNothing();
          break;
    }
  }
}

Here, a specific action must be taken depending on the weather. This kind of code is pretty hard to test and maintain. This short article aims to refactor it using a Map.