Software Testing

Tests are an essential part of any codebase. At a minimum, they help prevent regressions as the code evolves. But not all tests are created equal — unit, integration, component, contract, and end-to-end tests each serve a distinct purpose.

This article presents a practical strategy for testing Java Spring Boot microservices, covering the role, scope, and tooling for each test type to help you make the most of your test suite.

Component tests check full use cases from start to finish. They’re essential for verifying and documenting how an application or service behaves overall. But they can be expensive, especially in terms of setup and execution time — which is why it’s important to define their scope carefully.

That said, I’ve often found them cost-effective in distributed architectures. They’re usually simple to set up since you can reuse the service’s external API without needing extras like fake servers. And since each microservice tends to have a narrow focus, you can test behavior thoroughly in isolation.

This article explores how to make component tests more robust — with one key idea: keep them independent of implementation details.

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.