Menu

Introduction aux tests de contrat avec des exemples

introduction contract testing with examples

Essayez Notre Instrument Pour Éliminer Les Problèmes

quel est le meilleur nettoyeur d'ordinateur gratuit?

Ce didacticiel de test de contrat Pact explique ce qu'est le test de contrat axé sur le consommateur, comment cela fonctionne et pourquoi devriez-vous l'utiliser dans votre stratégie de test:

Qu'est-ce que le test de contrat?

Le test de contrat axé sur le consommateur est une forme de test d'API qui permet véritablement de passer à gauche. L'outil de contrat que nous utilisons est Pact.io , et nous en reparlerons plus tard dans cette série de tutoriels.

Le test de contrat est une méthode permettant de vérifier indépendamment l'intégration entre deux applications afin de tester ce qui a été réussi et de voir si ce qui est retourné correspond au «contrat».

Les tests de contrat s'intègrent parfaitement dans une architecture de microservices, fonctionnant dans un environnement agile. Par conséquent, les exemples seront basés sur l'expérience que nous avons acquise en travaillant dans cet environnement.

Test de contrat

Ce que vous apprendrez:

Liste des didacticiels de cette série de tests de contrat

Tutoriel n ° 1: Introduction aux tests de contrat avec des exemples (Ce tutoriel)
Tutoriel n ° 2: Comment rédiger un test de pacte de consommation en JavaScript
Tutoriel n ° 3: Comment publier un contrat Pact pour Pact Broker
Tutoriel n ° 4: Vérifiez le contrat Pact et le déploiement continu avec Pact CLI

Test de contrat axé sur le consommateur

Le point de départ est votre documentation API qui forme le contrat pour vos tests, à ce stade généralement, les équipes de développement prennent le document API et développent par rapport au document wiki (ou quel que soit le format dans lequel il réside dans votre organisation, tel que Document Word).

Par exemple, une application Web où le front-end est développé par Team Krypton et l'API est en cours de développement par Team Thoron. Le projet commence par une réunion de lancement où les exigences sont présentées et convenues entre les équipes.

Chaque équipe prend les exigences et commence à créer le backlog en affinant les histoires. Le développement commence dans les deux équipes en suivant les user stories, les tests d'intégration sont laissés pour les sprints ultérieurs. À mesure que Team Krypton trouve des exigences supplémentaires, relatives aux scénarios d'erreur, la documentation de l'API est mise à jour en conséquence.

Les cas de test sont ajoutés par l'équipe Thoron en fonction des scénarios mis à jour basés sur la documentation.

Nous pouvons déjà voir quelques défauts avec ce processus, et j'en ai ajouté quelques autres pour vous souhaiter bonne chance:

  1. Les modifications apportées aux documents de l'API peuvent ne pas être communiquées efficacement.
  2. L'équipe front-end supprime le service back-end et vice versa.
  3. L'équipe back-end crée des cas de test d'intégration basés sur la documentation.
  4. L'environnement d'intégration est la première fois que l'intégration complète est testée.
  5. Version d'API différente sur l'environnement d'intégration et la production.

Les tests contractuels axés sur le consommateur ont deux côtés, à savoir le consommateur et le fournisseur. C'est là que la pensée traditionnelle sur les tests dans les microservices est inversée.

La Consommateur est le conservateur des scénarios, y compris la demande et la réponse attendue. Cela vous permet de suivre Loi du lit ce qui vous oblige à être flexible dans ce que votre API peut accepter, mais prudent dans ce qui est envoyé. En revenant aux défauts no. 1, 3 et 4, les modifications de la documentation sont pilotées par le consommateur.

Par exemple, dans le cas où Team Thoron modifie un champ de chaîne pour ne pas accepter les valeurs nulles, les tests consommateur ne refléteraient pas le changement et échoueraient donc. Ou du moins jusqu'à ce que les changements aient été apportés à Team Krypton.

Définir les attentes des consommateurs

(image la source )

La Fournisseur vérifie les scénarios fournis par le consommateur par rapport à leur environnement «dev». Cela permet à vos microservices d'appliquer Changement parallèle qui stipule que vous devez étendre la fonctionnalité de l'API, puis migrer vers une nouvelle version. En revenant à la faille no. 2, les stubs généralement créés par les équipes back-end pour leurs propres exigences de test peuvent désormais être basés sur les scénarios de consommation utilisant Serveur de stub Pact .

Vérifier les attentes sur le fournisseur

L'élément contraignant des deux parties est le «contrat» qui doit être partagé entre les équipes. Le pacte fournit une plate-forme pour permettre le partage de contrats appelé le Courtier Pacte (disponible en tant que service géré avec Pactflow.io ).

La Courtier stocke la sortie des scénarios de consommation. Le contrat est ensuite stocké dans le courtier avec la version de l'API. Cela permet de tester contre plusieurs versions de l'API, ainsi la compatibilité peut être confirmée avant la publication, comme souligné dans la faille n ° 5.

pact_network_diagram
Pact Broker - Représentation visuelle

Un avantage supplémentaire du Pact Broker dans les anciennes plates-formes est la visibilité des consommateurs. Tous les consommateurs ne sont pas connus des auteurs de l'API, en particulier ce n'est pas la façon dont ils sont consommés.

Se référant spécifiquement à une occurrence où deux versions d'API étaient prises en charge, il y avait un problème de données dans la version 1 (V1) à cause duquel l'API causait données sales dans la base de données.

Le changement a été implémenté dans la V1 de l'API et poussé à la production, cependant, le consommateur s'est appuyé sur le format qui causait le problème de données, rompant ainsi leur intégration avec l'API.

Comment ça marche

Flux d

L'exemple ci-dessus montre le flux d'authentification, le service Web oblige les utilisateurs à s'authentifier pour accéder aux données sensibles. Le service Web envoie une demande à l'API pour générer un jeton à l'aide d'un nom d'utilisateur et d'un mot de passe. L'API renvoie un jeton de support qui est ajouté à la demande de données en tant qu'en-tête d'authentification.

Le test Consumer construit une requête POST pour un jeton en passant le corps avec le nom d'utilisateur et le mot de passe.

Demande POST

Un serveur fictif est lancé pendant le test qui valide la demande que vous construisez, ainsi que la réponse attendue qui, dans cet exemple, inclut la valeur du jeton.

serveur simulé

La sortie du test consommateur génère un fichier de contrat de pacte. Cela sera stocké dans le courtier pact en tant que version 1.

Le fournisseur extrait ensuite la version 1 du courtier pact et relit cette demande par rapport à son environnement local, en vérifiant que la demande et la réponse correspondent aux exigences du consommateur.

courtier pacte

Rôles et responsabilités

Rôles et responsabilités

Assurance qualité (QA) / testeur: Création de contrats avec Pact.io et collaboration avec la BA pour générer les scénarios de test.

Développeur: Association avec le contrôle qualité pour créer les tests et aider à encapsuler l'API pour l'implémentation en intégration continue (CI).

Analyste d'affaires (BA): Générer les scénarios et travailler avec l'architecte pour vérifier les parties concernées.

Architecte de solution (Peut ne pas exister dans votre organisation): Action des changements de l'API et coordination avec le BA sur la mise en œuvre, communiquant également les changements aux consommateurs (en utilisant le Pact Broker pour comprendre qui cela peut concerner).

Gestion des versions: (Oui, je sais que c'est démodé, mais cela existe toujours dans mon monde): Je suis convaincu que les modifications seront publiées avec succès grâce à la couverture des tests contractuels.

Équipe entière: Vérifiez les résultats pour déterminer si les versions peuvent être mises en production avec l'outil CLI Pact, Puis-je déployer .

Test de contrat vs test d'intégration

Des tests d'intégration doivent exister pour valider si le système fonctionne avant la promotion vers l'environnement de production, mais les scénarios peuvent être considérablement réduits.

L'impact de ceci pourrait être:

  • Rétroaction plus rapide avant la publication dans l'environnement d'intégration.
  • Moins de dépendance à la stabilité de l'environnement d'intégration.
  • Moins d'environnements prenant en charge plusieurs versions d'API.
  • Réduction des instances d'environnement instable en raison de problèmes d'intégration.
L'intégrationContracter
Échec clairement identifiéDe nombreuses couchesTrès facile
Configuration de l'APIOuiNon
Vérifications de déploiementOuiNon
Gestion des versions d'APIOuiOui
Déboguer localementNonOui
Problèmes environnementauxOuiNon
Temps de rétroactionLentVite

Premièrement, les tests contractuels ne remplacent pas les tests d'intégration. Mais il peut probablement remplacer certains de vos scénarios de test d'intégration existants, passer à gauche et fournir des informations plus rapides sur le cycle de vie de votre développement logiciel.

où trouvez-vous la clé de sécurité réseau

Lors des tests d'intégration, vous vérifierez le contexte dans lequel vit l'API, comme l'architecture de l'environnement, le processus de déploiement, etc.

Par conséquent, vous souhaitez exécuter les scénarios de test de base qui confirmeraient la configuration, par exemple, le point de terminaison de vérification de l'état de la version de l'API. Prouver également si le déploiement a réussi en renvoyant une réponse 200.

Dans les tests de contrat, vous testez les spécificités de l'API, qui incluent les cas extrêmes liés à la structure de l'API, au contenu (par exemple, les valeurs de champ, les clés existent) et les réponses aux erreurs. Par exemple, L'API gère-t-elle les valeurs nulles ou sont-elles supprimées de la réponse de l'API (un autre exemple réel).

Quelques avantages (si vous n'êtes pas déjà vendu)

Vous trouverez ci-dessous quelques-uns des avantages dont vous pouvez tirer parti lors de la vente de tests contractuels à l'entreprise au sens large:

  • Déploiement plus rapide des logiciels
  • Une seule source de vérité
  • Visibilité de tous les consommateurs
  • Facilité de test avec différentes versions d'API.

Questions fréquemment posées

Certaines questions courantes en essayant de persuader les gens d'adopter des tests contractuels incluent:

Q # 1) Nous avons déjà une couverture de test à 100%, donc nous n'en avons pas besoin.

Répondre: Eh bien, c’est impossible, mais les tests sous contrat présentent de nombreux autres avantages que la simple couverture des tests.

Q # 2) Il incombe à l'architecte de solution de communiquer les modifications de l'API.

Répondre: La qualité est la responsabilité de toute l’équipe.

Q # 3) Pourquoi créons-nous les scénarios de test pour l'équipe API?

Répondre: L'équipe API ne sait pas comment fonctionne le service Web, alors pourquoi devrait-il en être responsable.

Q # 4) Nos tests de bout en bout couvrent l'ensemble du flux du début à la fin, y compris d'autres points d'intégration.

Répondre: C'est exactement pourquoi nous divisons les tests pour tester une chose et il n'est pas de votre responsabilité de tester le flux de bout en bout d'un système dont vous ne savez pas comment il fonctionne.

Q # 5) Dans le référentiel de quelle équipe les tests se déroulent-ils?

Répondre: Tous les deux. Le consommateur dans son référentiel et le fournisseur dans le sien. Ensuite, au point central, le contrat vit en dehors de l'un ou l'autre.

Arguments

Voici les arguments contre lesquels nous avons du mal à nous opposer lorsqu'il s'agit de passer au contrat pour tester:

  • Documentation Swagger déjà en place qui peut être utilisée pour générer des tests d'intégration.
  • Les équipes possèdent à la fois des services frontaux et back-end avec un mécanisme efficace pour les changements d'API.

Intégration continue

Comment cela s'intègre-t-il dans votre suite de tests d'intégration continue? L'endroit idéal pour vivre les tests contractuels est vos tests unitaires.

Les tests consommateurs lancent un serveur fictif qui ne nécessite aucune dépendance externe en dehors du test.

Les tests de fournisseur nécessitent une instance d'API, par conséquent l'API locale peut être encapsulée à l'aide d'un serveur de test en mémoire . Cependant, s'il n'est pas facile d'encapsuler votre API localement, une solution de contournement que nous avons utilisée précédemment consiste à créer un environnement et à déployer le code dans cet environnement dans le cadre des vérifications automatisées de la demande d'extraction.

Intégration continue

Vidéo d

Intégration continue 3

(image la source )

Conclusion

Dans ce didacticiel, nous avons appris ce que signifie le test de contrat et à quoi il ressemble dans une infrastructure de microservices, et avons vu à quoi il ressemble dans un exemple réel.

Des leçons ont été apprises sur la façon dont les tests de contrat peuvent vous aider à déplacer vos tests d'intégration vers la gauche. De plus, nous avons vu comment cela peut réduire les coûts pour votre organisation en réduisant les délais de rétroaction liés aux problèmes d'intégration.

Les tests contractuels ne sont pas seulement un outil de test technique, ils renforcent la collaboration des équipes de développement en communiquant les changements et en encourageant les tests en une seule unité. Dans l'ensemble, cela devrait être une condition préalable pour toute personne souhaitant passer au déploiement continu.

Tutoriel SUIVANT

lecture recommandée

^