Dans le dernier article, nous décrivions les tests de composant, tests mi-unitaires mi-intégration permettant de valider à la fois l’intégration au sein de notre application (injection de dépendances) et aussi avec les composants périphériques. Le tout en restant suffisamment isolés de ces derniers pour limiter les frottements à l’exécution. L’isolation fonctionnant à merveille, le test de client d’API souffre d’un défaut majeur : lorsque le fournisseur change la signature du service, nous en sommes au courant bien trop tard. C’est ce que les tests de contrats tentent de parer et que nous allons aborder dans cet article.
body .gist .highlight { background: #202020; } body .gist tr:nth-child(2n+1) { background: #202020; } body .gist tr:nth-child(2n) { background: #202020; } body .gist .gist-meta { display:none; } body .gist .blob-num, body .gist .blob-code-inner, body .gist .pl-s2, body .gist .pl-stj { color: #f8f8f2; } body .gist .pl-c1 { color: #ae81ff; } body .gist .pl-enti { color: #a6e22e; font-weight: 700; } body .gist .pl-st { color: #66d9ef; } body .gist .pl-mdr { color: #66d9ef; font-weight: 400; } body .gist .pl-ms1 { background: #fd971f; } body .gist .pl-c, body .gist .pl-c span, body .gist .pl-pdc { color: #75715e; font-style: italic; } body .gist .pl-cce, body .gist .pl-cn, body .gist .pl-coc, body .gist .pl-enc, body .gist .pl-ens, body .gist .pl-kos, body .gist .pl-kou, body .gist .pl-mh .pl-pdh, body .gist .pl-mp, body .gist .pl-mp1 .pl-sf, body .gist .pl-mq, body .gist .pl-pde, body .gist .pl-pse, body .gist .pl-pse .pl-s2, body .gist .pl-mp .pl-s3, body .gist .pl-smi, body .gist .pl-stp, body .gist .pl-sv, body .gist .pl-v, body .gist .pl-vi, body .gist .pl-vpf, body .gist .pl-mri, body .gist .pl-va, body .gist .pl-vpu { color: #66d9ef; } body .gist .pl-cos, body .gist .pl-ml, body .gist .pl-pds, body .gist .pl-s, body .gist .pl-s1, body .gist .pl-sol { color: #e6db74; } body .gist .pl-e, body .gist .pl-ef, body .gist .pl-en, body .gist .pl-enf, body .gist .pl-enm, body .gist .pl-entc, body .gist .pl-entm, body .gist .pl-eoac, body .gist .pl-eoac .pl-pde, body .gist .pl-eoi, body .gist .pl-mai .pl-sf, body .gist .pl-mm, body .gist .pl-pdv, body .gist .pl-som, body .gist .pl-sr, body .gist .pl-vo { color: #a6e22e; } body .gist .pl-ent, body .gist .pl-eoa, body .gist .pl-eoai, body .gist .pl-eoai .pl-pde, body .gist .pl-k, body .gist .pl-ko, body .gist .pl-kolp, body .gist .pl-mc, body .gist .pl-mr, body .gist .pl-ms, body .gist .pl-s3, body .gist .pl-smc, body .gist .pl-smp, body .gist .pl-sok, body .gist .pl-sra, body .gist .pl-src, body .gist .pl-sre { color: #f92672; } body .gist .pl-mb, body .gist .pl-pdb { color: #e6db74; font-weight: 700; } body .gist .pl-mi, body .gist .pl-pdi { color: #f92672; font-style: italic; } body .gist .pl-pdc1, body .gist .pl-scp { color: #ae81ff; } body .gist .pl-sc, body .gist .pl-sf, body .gist .pl-mo, body .gist .pl-entl { color: #fd971f; } body .gist .pl-mi1, body .gist .pl-mdht { color: #a6e22e; background: rgba(0, 64, 0, .5); } body .gist .pl-md, body .gist .pl-mdhf { color: #f92672; background: rgba(64, 0, 0, .5); } body .gist .pl-mdh, body .gist .pl-mdi { color: #a6e22e; font-weight: 400; } body .gist .pl-ib, body .gist .pl-id, body .gist .pl-ii, body .gist .pl-iu { background: #a6e22e; color: #272822; } body .gist .gist-file, body .gist .gist-data { border: 0px; border-bottom: 0px; }
Lorsqu’on parle d’architecture microservice, il est fort probable que les services communiquent entre eux et on court à la catastrophe si l’on n’adopte pas certains patterns et notamment une parfaite autonomie :
C’est sur ce dernier point que les tests de contrats vont nous aider. Il s’agit d’un excellent complément aux tests de composants lorsqu’on parle de (micro)services. En effet, les tests de contrats vont permettre de vérifier que le contrat entre un fournisseur et un consommateur est toujours celui initialement défini entre les deux parties :
On entend souvent parler de Consumer-Driven Contracts, un pattern qui vise à co-construire les contrats à partir des besoins des consommateurs plutôt que de leur imposer celui définit par le fournisseur. Cela afin de limiter les frottements lors d’évolutions du service (gestion de la compatibilité montante et descendante, versions, ... généralement imposé par le fournisseur), mais également pour mieux connaître l’usage réel qui est fait du service (quels endpoints, quelles valeurs sont utiles).
Voilà donc ce que cela donnerait dans notre exemple :
Pour implémenter ce type de tests, je suis resté dans la nébuleuse Spring en utilisant Spring Cloud Contract, mais il existe d’autres frameworks et notamment l’un des plus connus, Pact.
Faisons donc un zoom sur ces tests :
Côté fournisseur nous aurons besoin de deux choses :
La baseClassForTests est une classe mère qui sera utilisée par tous les tests générés, nous y reviendrons.
La première étape vise donc à créer un contrat (au format yaml ou avec un DSL groovy), dans lequel on décrit la requête et la réponse. L’exemple suivant est simpliste, il est possible de faire des choses bien plus poussées (notamment avec des expressions régulières ou autres, je vous invite à lire la doc). On stockera ce contrat côté fournisseur dans le répertoire src/test/resources/contracts, avec le corps de la réponse, également dans un fichier :
À ce moment si vous exécutez Maven, le mécanisme va se mettre en place… ou du moins en partie. La classe de test va être générée (dans target/generated-test-sources/contracts) :
Mais le test va échouer…
En effet, nous avons besoin de la classe de base dont nous parlions plus haut pour initialiser un contexte et faire en sorte que le test passe :
Pas mal de choses à ce niveau :
À ce moment-là, les tests côté fournisseur devraient passer, et si vous avez lancé un mvn install ou deploy, le jar contenant les stubs devrait être publié dans le repo Maven (local ou distant) :
Installing connection-lookup/target/connection-lookup-0.0.1-SNAPSHOT-stubs.jar to ~/.m2/repository/ch/octo/blog/connection-lookup/0.0.1-SNAPSHOT/connection-lookup-0.0.1-SNAPSHOT-stubs.jar
Passons à présent côté consommateur (notre module journey-booking).
Nous avons ici besoin de la dépendance permettant d’utiliser le stub généré côté fournisseur :
Par ailleurs, il nous faut remplacer la dépendance wiremock avec celle de Spring Cloud sous peine d’avoir une exception. Si vous vous souvenez de notre test du client, nous utilisions wiremock pour simuler un serveur. Spring Cloud fait de même mais se base sur le stub auto-généré, ce qui permet d’être aligné avec le contrat du fournisseur.
Le code est le suivant (lien gitlab) :
Le test est relativement proche de notre test de composant (ConnectionLookupClientCompTest), à ceci près que nous ne manipulons plus wiremock directement. C’est l’annotation @AutoConfigureStubRunner qui va configurer le stub, en allant chercher la dépendance Maven spécifiée par l’attribut ids (au format groupId:artifactId:version:classifier) et en l’exposant sur le port 8090.
En utilisant le + comme numéro de version, on s’assure de prendre la plus récente, ce qui permet de vérifier que notre test passe toujours malgré les évolutions du fournisseur. Le jour où le test ne passe plus, nous savons que le contrat a changé, logiquement avant que le fournisseur ait mis en production la nouvelle version...
Comme nous venons de le voir, le test de contrat n’est autre qu’un test de composant, mais il a en plus l’avantage de valider que fournisseur et consommateur(s) sont toujours alignés. Je ne saurais donc que recommander d’utiliser ce dernier, en tout cas dans un environnement maîtrisé (typiquement des microservices au sein de votre entreprise). Cela n’a pas de sens lorsqu’on utilise une open API (typiquement l’API de transport), dans ce cas, on restera sur un test de composant.
Dans les 2 cas, je considère ces tests suffisamment importants et relativement rapides à exécuter pour être intégrés au build continu, encore et toujours dans l’objectif d’avoir une feedback rapide.
Les tests de contrats, souvent associés au pattern Consumer-Driven Contracts, sont donc un excellent moyen de vérifier que consommateur et fournisseur d’un service (qu’il soit REST ou via un message) sont toujours alignés sur un contrat commun et partagé. Ils ont également l’avantage de s’exécuter assez rapidement (isolation grâce à wiremock) et donc intégrables à la chaîne d’intégration continue. Dans le prochain article, nous aborderons des tests beaucoup moins simples à exécuter puisqu’il s’agit des tests d’intégration et tests de bout en bout.