Comment se moquer d’une API Rest en Python


Il y a quelques articles, nous avons publié un blog sur comment utiliser l’API Jira. Nous n’avons pas écrit de tests unitaires pour l’application que nous avons écrite, et c’est exactement ce que nous allons faire maintenant. Plus précisément, nous nous concentrerons sur la façon dont nous pouvons tester unitaire une API REST.

Pourquoi des tests unitaires de toute façon?

Notre objectif principal lors de l’écriture de logiciels est de créer de nouvelles fonctionnalités et de corriger les bugs. Bien sûr, nous devons tester ce que nous avons construit, mais nous obtenons le moment le plus joyeux lorsque notre fonctionnalité nouvellement développée fonctionne. La prochaine étape est d’écrire des tests unitaires… Mais, nous savons déjà que cela fonctionne, alors pourquoi y consacrer autant d’efforts? C’est beaucoup plus amusant de commencer avec la prochaine fonctionnalité, non? Donc, nous sautons l’écriture des tests unitaires. Mais que se passe-t-il lorsque nous devons étendre la fonctionnalité que nous avons écrite avec de nouvelles fonctionnalités?

Comment allons-nous nous assurer que nous n’avons pas cassé la fonction d’origine? Et si nous voulons refactoriser le code que nous avons écrit? Ce sont les moments où nous sommes heureux lorsque nous remarquons que quelqu’un a pris l’effort d’écrire des tests unitaires. Les tests unitaires nous donneront l’assurance que nous n’avons rien cassé lorsque nous avons changé du code (en supposant que les tests unitaires sont bien écrits et fournissent une couverture de code suffisante). Il est donc également courant d’exécuter les tests unitaires dans le cadre de votre pipeline CI / CD.

Si vous n’aimez pas écrire des tests unitaires après avoir développé une nouvelle fonctionnalité, vous pouvez également envisager d’écrire d’abord vos tests unitaires, de les laisser échouer, et lorsque vous implémentez votre code, les tests unitaires passeront (TDD: Test Driven Development). De cette façon, lorsque vous avez atteint votre plus haut moment de joie (ça marche!), Vous avez également réussi vos tests unitaires (tous les tests unitaires ont réussi!). Cela double votre moment de joie ;-).

Créez votre premier test unitaire

Nous nous appuierons sur sources du générateur de rapport de temps Jira. Nous utilisons Python 3.7 et PyCharm comme IDE. Commençons par créer un test répertoire et faites un clic droit sur le répertoire dans PyCharm. Choisir New - Python File et Python unit test. Cela crée le fichier par défaut suivant:

L’exécution de ce test unitaire échoue évidemment (True n’est pas égal à False), mais nous avons mis en place les bases pour écrire nos propres tests unitaires maintenant.

Se moquer d’une API Rest

Nous voulons tester les get_updated_issues fonction et cela nous fournit un premier défi: la get_updated_issues contient un appel à l’API Jira Rest. Nous ne voulons pas que notre test unitaire soit dépendant d’un service tiers, et par conséquent, nous avons besoin d’un moyen de se moquer de l’API Rest. Il existe plusieurs options pour se moquer d’une API REST, mais nous utiliserons le demandes-maquette Bibliothèque Python, qui correspond à nos besoins.

Installez le requests-mock Bibliothèque Python:

Tester la réponse d’une seule page

le get_updated_issues La fonction demandera les problèmes qui sont mis à jour dans un certain laps de temps. Dans notre test unitaire, nous vérifierons le comportement lorsqu’une page avec des résultats est récupérée (l’API Rest prend en charge la pagination, mais c’est quelque chose pour un prochain test unitaire):

Examinons de plus près ce qui se passe ici. Nous avons défini la réponse Jira JSON dans le fichier issues_one_page.json. Aux lignes 2 et 3, nous lisons le contenu du fichier dans la variable mock_response. À la ligne 5, nous définissons le résultat attendu avec une variable expected_result quand la fonction get_updated_issues Retour. Aux lignes 11 à 13, la magie opère.

Nous enregistrons l’URI que nous appelons depuis le get_updated_issues fonctionner avec le Mocker nous avons défini. Le troisième paramètre de register_uri définit la réponse, qui doit être renvoyée par l’appel d’API simulé. À la ligne 15, nous appelons le get_updated_issues fonction, et à la fin, nous vérifions si la réponse est égale au résultat attendu.

Test de la réponse paginée

L’API Jira prend en charge la pagination. Nous avons ajouté des fonctionnalités au get_updated_issues fonction afin de gérer les réponses paginées. La réponse JSON contient trois champs pour cela:

  • startAt: indique à partir de quel résultat la page doit être récupérée.
  • maxResults: le nombre de résultats maximum renvoyés dans une réponse.
  • total: le nombre total de résultats.

le maxResults pour récupérer les problèmes est, au moment de la rédaction de ce rapport, 50. Si nous voulons tester cela sur un vrai serveur Jira, nous devons créer au moins 51 problèmes. Mais pour les tests avec notre test unitaire, nous pouvons facilement changer la réponse afin que ce champ maxResults renvoie 2 par exemple, ce qui le rend beaucoup plus facile à tester. Notre test unitaire paginé se présente comme suit:

Le test unitaire ressemble assez à celui de la réponse d’une seule page. Nous avons défini deux réponses fictives cette fois, car l’API Jira sera appelée deux fois et nous voulons retourner deux réponses différentes. le expected_result La variable contient le résultat combiné des deux appels d’API. La vraie différence peut être vue à la ligne 17. Au lieu de définir une réponse simulée unique, nous définissons maintenant une liste de réponses simulées. Lorsque l’API est appelée plus que les réponses définies, la dernière réponse factice définie est renvoyée.

Test échoué

Les tests unitaires passent avant tout. Mais échouent-ils quand quelque chose ne va pas? On peut donc changer la ligne suivante dans le get_updated_issues une fonction:

avec:

Cela garantira que seule la réponse du premier appel d’API sera ajoutée à la liste des problèmes renvoyés, mais pas la réponse des appels d’API suivants. Exécutez à nouveau les deux tests. le test_get_updated_issues_one_page passe, mais le test_get_updated_issues_multiple_pages échoue:

Tester plusieurs URI

Les journaux de travail Jira doivent être récupérés par problème. Nous devons enregistrer plusieurs URI avec des réponses différentes pour chaque problème. La réponse du get_work_logs renvoie une liste de WorkLog des objets que l’on peut affirmer.

Conclusion

La rédaction de tests unitaires est absolument nécessaire lorsque vous souhaitez développer un logiciel de manière professionnelle. Dans cet article, nous avons examiné comment tester de manière unitaire une API Rest au moyen du requests-mock Bibliothèque Python. Nous n’avons fait qu’effleurer la surface de ce que cette bibliothèque a à offrir, mais nos premières impressions sont très bonnes.

Auteur de l’article : manuboss