Software Testing

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.

La version 1.4 de Spring Boot est sortie le 28 juillet 2016. Elle contient notamment des évolutions importantes au niveau de l’écriture des tests.
L’objectif de cet article est de voir comment migrer les tests d’un controller Spring MVC en utilisant les nouvelles fonctionnalités apportées par cette version.

L’Acceptance Test Driven Development est une pratique qui consiste à écrire un test d’acceptation dès la définition de la fonctionnalité à implémenter. Ce test permet ensuite de valider que l’implémentation de la fonctionnalité est terminée. En général, plusieurs composants unitaires sont nécessaires pour implémenter une fonctionnalité. Ces composants peuvent être développés en TDD dans une deuxième boucle de feedback.

L’objectif de cet article est de présenter l’ATDD et comment le mettre en pratique grâce à du TDD double boucle.