Comment testez-vous un service Spring qui utilise une base de données et appelle une autre API ?

Testez la logique métier avec du JUnit simple et sans contexte Spring, puisque l'injection par constructeur rend cela trivial. Testez la persistance contre une vraie base dans un conteneur plutôt qu'un substitut en mémoire, parce que les dialectes diffèrent et que les migrations doivent être testées aussi. Utilisez des tranches de test plutôt que de démarrer toute l'application pour les tests de contrôleur ou de repository, et bouchonnez l'API externe au niveau HTTP pour que votre code client, les reprises et le parsing s'exécutent vraiment.

L'essentiel de la logique reçoit de simples tests unitaires sans aucun framework : l'injection par constructeur veut dire que je peux instancier la classe avec des doublures pour ses collaborateurs et que ça tourne en millisecondes. Pour la persistance j'utilise une vraie base, du même moteur et de la même version, dans un conteneur, avec les migrations appliquées au montage du test, si bien que la migration elle-même est vérifiée à chaque exécution. Une base en mémoire est plus rapide mais elle ment sur les dialectes et les contraintes, et j'ai livré une requête qui marchait dans les tests et échouait en production à cause de ça. Pour la couche web j'utilise une tranche qui charge juste le contrôleur et la sérialisation, pas toute l'application, parce que tout démarrer à chaque test est ce qui fait durer une suite vingt minutes. L'API externe est bouchonnée au niveau HTTP avec un serveur simulé, donc ma configuration client, mes délais, ma logique de reprise et mon mapping JSON sont exercés pour de vrai. Je réutilise aussi les conteneurs sur toute l'exécution et j'annule chaque test dans une transaction, ce qui garde les choses isolées et parallélisables.