Le Contract Testing est une approche innovante dans le domaine du test logiciel, basée sur des « contrats » préétablis qui définissent les attentes entre les services consommateurs et fournisseurs. En d’autres termes, il s’agit d’un pacte qui garantit la compatibilité entre les composants d’un système, assurant ainsi leur bon fonctionnement. Et en se concentrant sur des interactions qui sont souvent négligées, le Contract Testing offre une meilleure couverture de test. En outre, il favorise une communication plus claire et plus précise entre les équipes de développement et assure une plus grande stabilité du système, car tout changement qui violerait un contrat est détecté rapidement, réduisant ainsi les risques de défaillance de l’ensemble.
Nicolas Barlogis, ingénieur DevOps et coach technique / craftsmanship Inside, nous dévoile les secrets de cette méthode de tests qui répond aux défis des architectures distribuées, et favorise un développement plus rapide, plus fiable et plus collaboratif.
Peux-tu commencer par nous donner ta vision du Contract Testing ?
Les tests de contrats (ou Contract Testing) représentent une forme de test logiciel qui décrit toutes les interfaces d’échanges entre deux applications. Le plus souvent via des API Web, mais il peut également s’agir d’un client de messaging, d’un échange de fichiers JSON ou de fichiers plats sur FTP, de XML… Soit tous les moyens possibles pour que les deux applications puissent communiquer entre elles… à la condition qu’elles soient d’accord sur la façon de décrire les données : c’est ce principe de « contrat ». Cette notion de Contract Testing est apparue pour donner suite aux nombreux changements que peuvent connaître les API, et aux évolutions constantes des applications (modification d’un format, d’un champ, d’un simple chiffre…). Ces changements sont souvent opérés par le « provider », c’est-à-dire le système qui fournit des fonctionnalités ou des données pour une autre application ou un autre service. Mais si ces modifications semblent simples d’apparence, elles peuvent entrainer des bugs et des régressions du côté du « consumer », c’est-à-dire le système qui utilise des fonctionnalités ou des données exposées par une autre application ou un autre service.
Comment contrôler ces changements et pourquoi est-ce important pour les entreprises ?
L’idée est donc de s’assurer, avant d’effectuer un quelconque changement, que les 2 parties (provider et customer) respectent bien un contrat commun. Et il existe plusieurs méthodes pour procéder. L’une d’entre elle consiste à faire des tests unitaires (TU) de chaque côté. Le problème : chaque partie à sa propre façon de faire et les formats utilisés par les deux entités ne sont pas forcément les mêmes, ce qui peut amener… des régressions ! Une autre façon de procéder consiste à faire un test « end to end » dans un environnement de recette pour vérifier que tout fonctionne bien. Mais ce type de tests est couteux et arrive le plus souvent en fin de développement, avec des cycles longs. Enfin, la meilleure façon de faire aujourd’hui est représentée par le Contract Testing grâce à des librairies comme Pact (l’outil standard en la matière). Cette approche comporte des cycles d’exécutions rapides intégrants des TU et des TI (Tests d’Intégrations) et avec le même niveau de certitude qu’un test End to End. Concrètement si prenons le cas d’une API sur Pact, le consumer va décrire un contrat qui sera envoyé vers un serveur partagé. Puis consumer et provider vont écrire leurs tests autour de ce contrat. Ici, le format de donnée est donc partagé, ce qui supprime les problèmes qui peuvent apparaître avec des TUs séparés. Ainsi si le consumer vient à faire une régression ou si le provider change un format (par exemple), le test va le détecter automatiquement : le feedback est immédiat. C’est donc un gros gain de temps dans la détection des bugs, l’économie de couteux tests End to End, la réduction du cycle de développement et une réponse aux enjeux de qualité.
Comment une entreprise peut se rendre compte qu’elle a besoin de Contract Testing ?
Lorsqu’il y a beaucoup de régression dans le développement d’une solution, trop de tickets de bugs chez les consumers, des mises en production non maîtrisées… c’est qu’il y a certainement des changements non détectés (ou tardivement) chez le provider autour d’une API critique (dans le sens très sollicitée). Le recours au Contract Testing est alors souhaitable, notamment pour le développement d’applications basées sur des micro–services pour tester leurs interactions, l’intégration de systèmes disparates pour définir un contrat commun des interactions entre les systèmes, et le développement agile pour tester les interactions entre les composants dès les premières étapes du développement. Autre point : plus une entreprise est grande, plus il peut y avoir de distances entre les équipes, qui parfois ne se parlent jamais, et qui sont pourtant dépendantes techniquement. De fait, si des équipes dépendantes ne se connaissent pas, c’est un déclencheur du Contract Testing. Il sert donc également à améliorer la communication entre les équipes et les métiers ainsi que la connaissance du travail fournit par chacune, ce qui est forcément vertueux.
Comment initier la démarche de Contract Testing et comment Inside répond à cette problématique ?
Débuter une démarche de Contract Testing avec la librairie Pact n’est pas très complexe. Celle-ci est particulièrement mature, et dispose d’une très bonne documentation. Je conseille de commencer avec une petite API pour bien comprendre comment marche le système, avant de monter en gamme sur des scénarios de plus en plus complexes. Car souvent, les API critiques visées par le Contract Testing sont denses et les contrats peuvent être gigantesques, donc logiquement plus compliqués à tester. Dans ce contexte, Inside peut justement accompagner les équipes sur ces contrats particulièrement difficiles à mettre en œuvre.
Nous pouvons par exemple vérifier que la couverture de tests est efficiente, avec les bons TU et TI, pour ensuite étendre la démarche sur du Contract Testing ou du Mutation Testing (pour « tester les tests », en rendant le code volontairement “malade” avec des mutations afin d’observer la capacité des tests à bien diagnostiquer l’anomalie introduite). Ce qui implique que les équipes doivent déjà être conscientes de l’intérêt de ces tests, à l’image du Test Driven Dévelopment (TDD), le Contract Testing est une « brique » qui se positionne au début d’une démarche, pas à la fin (idéalement). Nous pouvons également accompagner les équipes dans l’étude de leurs interactions (entre ce qui est produit et ce qui est consommer) pour évaluer la criticité et les rythmes de changement, la distance et la maîtrise entre les équipes. Ce qui permet d’établir le bénéfice/risque et les API à tester, car il est impossible de faire du Contract Testing sur toutes les API d’une équipe.
Vous souhaitez échanger avec nos experts autour du Contract Testing, c’est par ici !
