Fermer

septembre 7, 2020

Comment automatiser les tests d'API avec Postman


À propos de l'auteur

Kelvin Omereshone est le directeur technique du Quru Lab . Kelvin était auparavant ingénieur Front-end chez myPadi.ng. Il est le créateur de la communauté Nuxtjs Africa et très passionné…
En savoir plus sur
Kelvin

Dans cet article, nous allons apprendre à écrire des tests automatisés sur des API Web avec Postman. Pour suivre ce didacticiel, vous aurez besoin d'au moins une bonne connaissance de Postman.

L'une de mes fonctionnalités préférées dans Postman est la possibilité d'écrire des tests automatisés pour mes API. Donc, si vous êtes comme moi et que vous utilisez Postman et que vous êtes fatigué de tester manuellement vos API, cet article vous montrera comment exploiter la fonction d'automatisation des tests fournie par Postman.

Au cas où vous ne sauriez pas ce qu'est Postman ou vous sont entièrement nouveaux pour Postman, je vous recommande de consulter la page de documentation de prise en main de Postman puis de revenir à cet article pour apprendre à automatiser le test de votre API avec Postman.

API ou API Web assez beaucoup pilotent la plupart des produits numériques destinés aux utilisateurs. Cela dit, en tant que développeur backend ou frontal, le fait de pouvoir tester ces API avec facilité et plus efficacement vous permettra de progresser rapidement dans votre cycle de développement.

Postman vous permet de tester manuellement vos API à la fois sur son bureau et applications Web. Cependant, il vous permet également d'automatiser ces tests en écrivant des assertions JavaScript sur vos points de terminaison d'API.

Pourquoi vous devriez automatiser les tests d'API

Les tests en développement logiciel sont utilisés pour vérifier la qualité de tout logiciel. Si vous créez des API en tant que backend pour une seule application frontale ou si vous créez des API destinées à être utilisées par plusieurs services et clients, il est important que les API fonctionnent comme prévu.

Configuration de tests API automatisés pour tester les différents points de terminaison dans votre API vous aidera à détecter les bogues le plus rapidement possible.

Elle vous permettra également de vous déplacer rapidement et d'ajouter de nouvelles fonctionnalités, car vous pouvez simplement exécuter les cas de test pour voir si vous cassez quoi que ce soit en cours de route.

Steps To Automating Tests API

Lors de l'écriture de tests API dans Postman, j'adopte normalement une approche en quatre étapes:

  1. Test manuel de l'API ;
  2. Comprendre la réponse renvoyée par l'API ;
  3. Ecrire le test automatisé ;
  4. Répétez pour chaque point de terminaison sur l'API.

Pour cet article, j'ai un service Web NodeJS optimisé par SailsJS qui expose les points de terminaison suivants pour:

  • / – le site de l'API.
  • / user / signup – Enregistre un nouvel utilisateur.
  • / user / signin – Se connecte à un utilisateur existant.
  • / listing / new – Crée une nouvelle liste (une liste est le détail d'une propriété appartenant par l'utilisateur) pour un utilisateur existant.

J'ai créé et organisé les points de terminaison pour le service de démonstration que nous utiliserions dans cet article dans une Postman collection afin que vous puissiez rapidement importer la collection dans Postman par Cliquez sur le bouton ci-dessous et suivez.

 Run in Postman

Alors suivons mes quatre étapes pour automatiser les tests API dans Postman.

1. Tester l'API manuellement

Je vais ouvrir Postman et basculer vers un espace de travail que j'ai créé appelé demo qui contient la collection postman-test-demo-service . Vous aurez également accès à la collection si vous l'avez importée d'en haut. Donc mon facteur ressemblerait à ceci:

 postman avec la collection `postman-test-demo-service`
( Large preview )

Notre premier test est de tester le point de terminaison domestique ( / ) de l'API. Je voudrais donc ouvrir la demande dans la barre latérale appelée home vous pouvez voir qu’il s’agit d’une demande Get et en appuyant simplement sur Entrée, j’enverrais une demande GET au service Web pour voir à quoi il répond. L'image ci-dessous montre cette réponse:

 réponse à une requête GET
( Grand aperçu )

2. Comprendre la réponse renvoyée par l'API

Si vous suivez le long et aussi de la capture d'écran ci-dessus, vous verrez la réponse est revenue avec un code d'état de 200 OK et également un corps JSON avec un message avec la valeur Vous avez atteint le service Web de démonstration de test postman

Sachant qu'il s'agit de la réponse attendue du point de terminaison / sur notre service, nous pouvons continuer à l'étape 3 – écrire le test automatisé proprement dit.

3. Écrire le test automatisé

Postman est prêt à l'emploi avec un moteur d'exécution puissant basé sur Node.js qui donne à ses utilisateurs la possibilité d'écrire des scripts dans le langage JavaScript.

Dans Postman, vous ajoutez des scripts à exécuter pendant deux événements dans le flux de travail Postman:

  • Avant de faire une demande.
    Ces scripts sont appelés script de pré-demande et vous pouvez les écrire sous l'onglet Script de pré-demande .
  • Après avoir reçu une réponse de la demande que vous avez faite.
    Ces scripts sont appelés scripts de test et c'est cet ensemble de scripts qui est notre objectif dans cet article. Vous écrivez des scripts de test sous l'onglet Tests dans une requête Postman.

L'image ci-dessous montre l'onglet Tests ouvert dans Postman:

 L'image montre l'onglet Tests ouvert dans Postman
( Grand aperçu )

Si vous regardez à votre droite dans l'onglet Tests de demande déjà ouvert, vous remarquerez une liste d'extraits disponibles pour vous permettre de commencer rapidement à écrire des tests. La plupart du temps, ces extraits sont suffisants pour un certain nombre de scénarios de test. Je choisirais donc le titre de l'extrait Code d'état: Le code est 200 . Cela générera le code ci-dessous dans l'éditeur Tests :

 pm.test ("Status code is 200", function () {
    pm.réponse.à.avoir.un.état (200);
}); 

Voici à quoi ressemblerait Postman après avoir cliqué sur cet extrait de test:

 À quoi ressemblerait Postman après avoir cliqué sur un extrait de test
( Grand aperçu ) [19659031] Si vous avez écrit une forme de test en JavaScript en utilisant certains des cadres de test comme Jest, alors l'extrait ci-dessus vous semblera familier. Mais laissez-moi vous expliquer: tous les scénarios ou combinaisons de test postman commencent par la fonction test () qui est exposée dans l'objet global pm (abréviation de Postman) fourni par Postman pour vous. La méthode test prend deux arguments: le premier est la description du test qui dans notre suite de tests ci-dessus se lit comme suit: Le code d'état est 200 le deuxième argument est une fonction de rappel. C’est dans cette fonction que vous faites vos affirmations ou vérifiez la réponse à la requête particulière testée.

Vous remarquerez que nous avons une seule assertion pour le moment, mais vous pouvez en avoir autant que vous le souhaitez. Cependant, j'aime garder les assertions dans des tests séparés la plupart du temps.

Notre assertion ci-dessus demande simplement à Postman si le retour de réponse a un code de statut de 200. Vous pouvez voir comment il se lit comme l'anglais. Ceci est intentionnel afin de permettre à quiconque d'écrire ces tests avec facilité.

Exécution de notre test

Pour exécuter notre test, nous enverrons à nouveau une requête au point final. Seulement cette fois-ci, lorsque Postman recevra la réponse de cette demande, il exécutera vos tests. Ci-dessous, une image montrant le test de réussite dans Postman (Vous pouvez accéder au résultat du test dans l'onglet Résultats du test de la section de réponse dans Postman):

 une image montrant le test de réussite dans Postman
( Grand aperçu )

Notre test a donc réussi! Cependant, il est crucial que nous fassions d'abord échouer notre scénario de test, puis que nous le réussissions; cela vous aidera à vous assurer que le scénario que vous testez n'est affecté par aucun facteur externe et que le test réussit pour la raison pour laquelle vous vous attendez à ce qu'il réussisse – pas autre chose. Un bon test doit être prévisible et le résultat final doit être connu à l'avance.

Pour faire passer notre test, je vais faire une faute de frappe dans l'URL à laquelle nous envoyons actuellement la requête GET. Cela conduira à un code d'état 404 Not Found qui fera échouer notre test. Faisons cela. Dans la barre d'adresse ayant actuellement la variable de notre baseUrl, j'ajouterai / a (cela pourrait être quelque chose de aléatoire en fait). Faire la demande à nouveau et notre test échouera comme indiqué ci-dessous:

 échec du test
( Grand aperçu )

En supprimant la chaîne / a le test passera

Nous avons écrit un test automatisé pour l'itinéraire d'origine de notre service Web de démonstration. Pour le moment, nous avons un cas de test vérifiant l'état de la réponse. Écrivons un autre scénario de test pour vérifier si le corps de la réponse contient une propriété message comme nous l'avons vu dans la réponse et que la valeur est "Vous avez atteint le service Web de démonstration de test postman". Ajoutez l'extrait de code ci-dessous à l'éditeur de test:

 pm.test ("Contains a message property", function () {
    laissez jsonData = pm.response.json ();
    pm.expect (jsonData.message) .to.eql ("Vous avez atteint le service Web de démonstration de test postman");
}) 

La fenêtre de votre facteur doit ressembler à ceci:

 fenêtre du facteur
( Grand aperçu )

Dans l'extrait de code ci-dessus, nous créons un cas de test et obtenons l'objet JavaScript équivalent du corps de réponse de la requête qui est à l'origine en JSON en appelant json () dessus. Ensuite, nous utilisons la méthode d'assertion expect pour vérifier si la propriété du message a la valeur «Vous avez atteint le service Web de démonstration de test postman».

4. Répétez!

D'après la première itération ci-dessus de nos 4 étapes d'écriture des tests d'API, je crois que vous avez vu le flux. Nous répéterions donc ce flux pour tester toutes les demandes du service Web de démonstration. La prochaine étape est la demande d'inscription. Testons maintenant!

Demande d'inscription

La demande d'inscription est une demande POST qui attend le nom complet, l'adresse e-mail et le mot de passe d'un utilisateur. Dans Postman, vous pouvez ajouter ces paramètres de plusieurs façons, mais nous opterons pour la méthode x-www-form-urlencoded dans les onglets Corps de la section requête. L'image ci-dessous donne un exemple des paramètres:

 un exemple des paramètres
( Grand aperçu )

Voici la réponse à la requête ci-dessus:

 {
    "message": "Un compte a été créé pour kelvinomereshone@gmail.com avec succès",
    "Les données": {
        "createdAt": 1596634791698,
        "updatedAt": 1596634791698,
        "id": "9fa2e648-1db5-4ea9-89a1-3be5bc73cb34",
        "emailAddress": "kelvinomereshone@gmail.com",
        "fullName": "Kelvin Omereshone"
    },
    "Jeton": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJrZWx2aW5vbWVyZXNob25lQGdtYWlsLmNvbSIsImlzcyI6Ik15UGFkaSBCYWNrZW5kIiwiaWF0IjoxNTk2NjM0NzkxfQ.otCcXSmhP4mNWAHnrYvvzHkgU8yX8yRE5rcVtmGJ68k"
} 
 la propriété de jeton est retournée avec le corps de réponse
( Grand aperçu )

À partir du corps de réponse ci-dessus, vous remarquerez qu'une propriété de jeton est renvoyée avec le corps de réponse. Nous écririons donc un cas de test pour affirmer si un corps de réponse JSON a été renvoyé et s'il contient la propriété token . En outre, nous vérifierions également le code de statut qui renvoie 201 Créé. Alors ouvrez l'onglet Tests et ajoutez les extraits suivants:

 pm.test ("Status code is 201", function () {
    pm.response.à.avoir.un.stat (201);
});


pm.test ("La réponse a un corps JSON", function () {
    pm.response.to.be.json;
});

pm.test ("La réponse a une propriété de jeton", function () {
    var jsonData = pm.response.json ();
    pm.expect (jsonData.token) .to.be.a ('chaîne');
});

Ce que fait chaque cas de test devrait être suffisamment évident d'après la description du test. De haut en bas, nous vérifions si la réponse est un code d'état 201 Created, nous affirmons également si le corps de la réponse est JSON et enfin nous affirmons si la propriété token a une valeur de type string. Faisons nos tests.

Note : Assurez-vous de modifier au moins l'adresse e-mail du nouvel utilisateur car le service Web n'autorisera pas les e-mails en double.

Nos tests doivent réussir et lorsque vous vérifiez l'onglet Résultats des tests de la section Réponse, vous devriez obtenir 3 tests réussis comme indiqué ci-dessous:

 3 tests réussis
( Grand aperçu )

Passons au test du point de terminaison signin

Signin Request

Le corps de la réponse de la demande de connexion est similaire à la demande d'inscription. Vous pouvez vérifier qu'en touchant le point de terminaison avec les informations d'identification de l'utilisateur – emailAddress et Password – vous vous êtes déjà inscrit. Après avoir fait cela, ajoutez les cas de test suivants à l'éditeur de tests:

 pm.test ("Status code is 200", function () {
    pm.réponse.à.avoir.un.état (200);
});


pm.test ("La réponse a un corps JSON", function () {
    pm.response.to.be.json;
});

pm.test ("La réponse a une propriété de jeton", function () {
    var jsonData = pm.response.json ();
    pm.expect (jsonData.token) .to.be.a ('chaîne');
});



pm.test ("La réponse a une propriété de données", function () {
    var jsonData = pm.response.json ();
    pm.expect (jsonData.data) .to.be.a ('objet');
}); 

Faites la demande de connexion avec un identifiant d'utilisateur valide et votre test devrait réussir et Postman devrait ressembler à ceci:

 Postman avec un test réussi
( Large preview ) [19659031] Enfin, nous testerions le point final listing / new de notre API de démonstration.

Listing / New Request

Ce test serait un peu différent. Conformément aux exigences de notre API fictive, seuls les utilisateurs connectés peuvent créer des listes. Nous aurions donc besoin d'un moyen d'authentifier la demande.

Rappel lorsque la signature d'un jeton JWT a été renvoyée, nous pouvons utiliser ce jeton comme en-tête d'autorisation pour la demande de création de liste.

Pour ce faire dans Postman, copiez simplement le jeton que vous avez obtenu en vous connectant et accédez à l'onglet Autorisation de la section Requête dans Postman et sélectionnez le type Bearer Token dans la liste déroulante Type. Vous pouvez ensuite coller le jeton dans la case à votre droite intitulée Token . Ainsi, le nouvel onglet Autorisation de demande devrait ressembler à ceci:

 le nouvel onglet Autorisation de demande
( Grand aperçu )

Vous pouvez ensuite ajouter les paramètres dans l'onglet Corps du demande. Vous remarquerez que le nom des champs est déjà là avec des exemples de valeurs que vous pouvez choisir de modifier ou non. Faisons une demande avant d'écrire notre test. Une réponse réussie ressemblera à ceci:

 {
    "message": "Nouvelle annonce créée avec succès",
    "Les données": {
        "createdAt": 1596637153470,
        "updatedAt": 1596637153470,
        "id": "41d922ce-7326-43eb-93c8-31658c59e45d",
        "name": "Glorious Lounge",
        "type": "Hôtel",
        "adresse": "Non 1. Quelque chose de rue",
        "rent": "100 000 $ par an",
        "lister": "9fa2e648-1db5-4ea9-89a1-3be5bc73cb34"
    }
} 

Nous pouvons voir que nous récupérons un corps de réponse JSON. Nous pouvons tester cela et nous assurer également que les données ne sont pas vides. Ajoutez le cas de test suivant à l'onglet Test:

 pm.test ("Status code is 200", function () {
    pm.réponse.à.avoir.un.état (200);
});


pm.test ("La réponse a un corps JSON", function () {
    pm.response.to.be.json;
});

pm.test ("La réponse a une propriété de message", function () {
    var jsonData = pm.response.json ();
    pm.expect (jsonData.message) .to.be.a ('chaîne');
});



pm.test ("La réponse a une propriété de données", function () {
    var jsonData = pm.response.json ();
    pm.expect (jsonData.data) .to.be.a ('objet');
}); 

Avec cela ajouté, faites une autre demande et les tests devraient tous réussir comme indiqué ci-dessous:

 test réussi
( Large preview )

Conclusion

Cet article vise à vous montrer comment utiliser Postman pour écrire des tests automatisés pour vos API, ce qui vous permettra de combler le fossé entre le développement et l'assurance qualité, et également de minimiser la surface des bogues dans votre API.

Additional Resources

 Smashing Éditorial (ks, ra, yk, il)




Source link