Introduction aux tests de contrats

blog-thumb

Introduction

Ces dernières années, l’architecture des microservices est devenue de plus en plus populaire. Elle est largement adoptée par plusieurs entreprises.

Avec une telle architecture et lorsqu’elle est réalisée correctement, elle offre plusieurs avantages:

  • Scalabilité
  • Hétérogénéité technologique
  • Réutilisabilité
  • Résilience
  • Maintenabilité

En revanche, dans le monde des microservices, la difficulté des tests d’intégration est un enjeu majeur !

Prenons un exemple simple d’une architecture composée de 10 microservices. Chaque service est géré par une équipe indépendante.

Ce scénario nous amène à nous poser les questions suivantes :

  • Comment tester les interactions entre les différents microservices ?
  • Comment assurer la compatibilité des versions entre les microservices ?
  • Comment gérer la synchronisation entre les différentes équipes ?

L’approche classique pour tester cette architecture consiste à déployer les microservices dans des environnements de test séparés, puis à exécuter des tests automatisés de bout en bout.

Et pour mettre en œuvre cette stratégie, certains prérequis sont nécessaires :

  • Synchronisation entre les différentes équipes
  • Préparation des jeux de données
  • Préparation de l’infrastructure

Sans surprise, l’efficacité de cette approche est généralement faible, on se retrouve avec :

  • Des tests de bout en bout fragiles
  • Une boucle de feedback lente
  • Un coût d’infrastructure élevé
  • Une augmentation du temps de test
  • Un travail supplémentaire de synchronisation

Cette approche de test est généralement plus adaptée aux architectures monolithiques mais pas aux microservices.

Existe-t-il d’autres approches de test plus efficaces ?

La réponse est oui, une stratégie de tests de contrats (Contract Testing) pourrait être une solution plus fiable et plus efficace à ce véritable challenge des tests d’intégration !

Les tests de contrats (Contract testing)

Qu’est-ce que c’est les tests de contrats ?

Les tests de contrats (Contract testing en anglais) est une technique de tests d’intégration inter-services.

Cette technique est généralement utilisée dans les architectures microservices. Elle permet de tester les points d’intégration en isolant chaque microservice et en vérifiant si les requêtes et les réponses HTTP transmises par le microservice sont conformes à une compréhension partagée et documentée dans un contrat.

De cette manière, les tests de contrats garantissent que les microservices peuvent communiquer entre eux.

Terminologies

Pour avoir une compréhension approfondie des tests contractuels, il est important de connaître les terminologies suivantes :

Consommateur (Consumer)

Le consommateur c’est l’application ou service (celui qui appelle l’API provider) qui utilise des fonctionnalités ou des données exposées par une autre application ou un autre service

Fournisseur (Provider)

Le fournisseur c’est l’application qui fournit (expose des services http) des fonctionnalités ou des données pour une autre application ou un autre service

Contrat

Un contrat est une forme documentée de compréhension partagée entre un consommateur et un fournisseur.

Les différentes approches de tests de contrats

Les trois approches les plus courantes sont celles utilisées par le projet PACT (Consumer-driven, provider-driven et Bidirectional) mais le principe reste valable avec d’autres outils ou technologies

Consumer-driven contract testing (CDCT)

Avec cette approche, chaque consommateur définit ses attentes (requêtes, réponses, messages) vis-à-vis d’un fournisseur Le contrat est donc généré par le consommateur et transmis au fournisseur Le fournisseur doit être en mesure de répondre à l’ensemble des attentes exprimées par le consommateur

Quand faire du consumer-driven ?

  • Nombre limité de consommateurs
  • Communication fluide entre les équipes
  • Ex: Backend for Frontend

Provider-driven contract testing (PDCT)

Avec cette approche c’est le fournisseur qui s’occupe de la définition des différentes interactions (requêtes, réponses, messages). Le consommateur doit donc respecter les spécifications fournies par le fournisseur. Un contrat axé sur le fournisseur ressemble beaucoup à une documentation technique.

Quand faire du provider-driven ?

  • Consumers inconnus
  • Nombre important de consommateurs
  • Communication difficile entre les équipes

Bidirectional contract testing (BDCT)

Avec cette approche:

  • Le fournisseur génère sa propre version du contrat
  • Le consommateur génère sa propre version du contrat
  • Une entité tierce s’occupe de la validation et la vérification des éventuels problèmes d’intégration

A titre d’exemple la plateforme Pactflow dispose d’une fonctionnalité payante de Bidirectional contract testing

Les outils de tests de contrats

L’outil (Open source) le plus utilisé pour le contract testing c’est l’outil Pact PACT est un écosystème pour faire des tests contractuels, il est composé de plusieurs éléments:

Il existe aussi d’autres outils comme:

  • Spring Cloud Contract (Uniquement pour Java) …

Notes importantes

  • Un contrat NE REMPLACE PAS une bonne communication entre les équipes !
  • Le Contract Testing NE REMPLACE PAS les tests fonctionnels
  • Le Contract Testing n’est pas recommandé pour les API Publiques
  • L’utilisation du CI/CD est nécessaire pour accélérer / maîtriser le workflow global

Ça vous intéresse ?

Voulez-vous en savoir plus sur les tests de contrats ?

Cet article vous a plu ❤️ ? N’hésitez pas à le partager pour que d’autres personnes puissent en profiter

comments powered by Disqus