Tests d'intégration avec Spring Boot

Une suite de tests Spring passe de quarante secondes à onze minutes sans qu'une seule ligne de logique métier ait été ajoutée. La cause est presque toujours la même : le contexte applicatif est reconstruit des dizaines de fois. Spring met le contexte en cache et le réutilise entre les classes de test, mais uniquement si la configuration demandée est strictement identique. Une classe qui ajoute un @MockBean, une propriété @TestPropertySource ou un profil différent obtient une clé de cache différente, donc un contexte neuf, donc trois à huit secondes de démarrage supplémentaires. Vingt variantes de configuration, c'est vingt démarrages.

Le second piège est symétrique : annoter toutes les classes de test avec @SpringBootTest par confort. Vous chargez alors le conteneur complet — sécurité, planificateur, clients HTTP, écouteurs de messages — pour tester une requête SQL de quinze lignes. Le test est lent, et il échoue pour des raisons sans rapport avec ce qu'il vérifie : un bean d'infrastructure absent en environnement de test suffit à faire tomber une classe qui n'y touche pas. La compétence à acquérir ici est de charger le moins possible tout en restant réaliste, et de limiter le nombre de configurations distinctes dans le projet.