Comment testez-vous que deux services fonctionnent toujours ensemble sans démarrer tout le système ?

Utilisez les tests de contrat. Le consommateur définit les requêtes qu'il envoie et la forme de réponse dont il dépend, cette attente est publiée comme un contrat, et le fournisseur la vérifie dans son propre pipeline. Les deux côtés testent alors indépendamment et vite, et un changement cassant fait échouer la build du fournisseur au lieu d'apparaître dans un environnement partagé des jours plus tard.

Les environnements de bout en bout complets ne passent pas l'échelle au-delà d'une poignée de services. Ils sont lents, ils exigent que la dernière build de chaque équipe soit saine en même temps, et quand quelque chose passe au rouge la première question est toujours de savoir si c'est un vrai défaut ou l'environnement. Le test de contrat contourne cela. Le consommateur écrit des tests contre un stub local du fournisseur, et ces interactions sont enregistrées comme un contrat : pour cette requête, je dépends de ces champs avec ces types. Ce contrat est publié, et le pipeline du fournisseur le rejoue contre l'implémentation réelle. Si quelqu'un renomme un champ ou change un type, sa build échoue, dans son dépôt, quelques minutes après le changement, avec un message qui nomme le consommateur cassé. C'est là toute la valeur : le retour atterrit là où le changement a été fait. La nuance à énoncer, c'est qu'un contrat ne couvre que ce que le consommateur utilise réellement, pas toute la surface du fournisseur, donc il ne remplace pas les tests fonctionnels du fournisseur, et il vérifie la compatibilité plutôt que la justesse métier. Je garde quand même une petite suite de bout en bout pour les quelques parcours qui méritent vraiment d'être prouvés à travers les services.