Comment tester les requêtes DELETE pour les tests d’API avec Playwright Java

Les tests API ont gagné beaucoup d’élan ces jours-ci. Comme l’interface utilisateur n’est pas impliquée, il est beaucoup plus facile et rapide de tester. C’est la raison pour laquelle les tests API sont considérés comme le premier choix pour effectuer des tests de bout en bout du système. L’intégration des tests API automatisés avec les pipelines CI/CD permet aux équipes d’obtenir un retour d’information plus rapide sur les builds.

Dans ce blog, nous discuterons et apprendrons sur les requêtes API DELETE et comment les gérer en utilisant Playwright Java pour les tests d’automatisation, en abordant les points suivants :

1. Qu’est-ce qu’une requête DELETE ?
2. Comment tester les API DELETE en utilisant Playwright Java ?

Commencer

Il est recommandé de consulter le blog tutoriel précédent pour en savoir plus sur les détails concernant les prérequis, la configuration, et la mise en place.

Application sous Test

Nous utiliserons les APIs RESTful e-commerce gratuites qui offrent plusieurs APIs liées à la fonctionnalité de gestion des commandes, nous permettant de créer, récupérer, mettre à jour et supprimer des commandes.

Cette application peut être configurée localement à l’aide de Docker ou NodeJS.

Qu’est-ce qu’une requête DELETE ?

Une requête API DELETE supprime la ressource spécifiée du serveur. En général, il n’y a pas de corps de réponse dans les requêtes DELETE.

La ressource est spécifiée par une URI, et le serveur la supprime définitivement. Les requêtes DELETE ne sont ni considérées comme sûres ni idempotentes, car elles peuvent avoir des effets secondaires sur le serveur, comme la suppression de données d’une base de données.

Voici quelques-unes des limitations des requêtes DELETE :

1. Les données supprimées par une requête DELETE ne sont pas réversibles, donc elles doivent être traitées avec soin.
2. Ce n’est pas considéré comme une méthode sûre car elle peut supprimer directement la ressource de la base de données, provoquant des conflits dans le système.
3. Ce n’est pas une méthode idempotente, ce qui signifie que l’appel à plusieurs reprises pour la même ressource peut entraîner des états différents. Par exemple, lors de la première instance, lorsque DELETE est appelé, il renverra le code d’état 204 indiquant que la ressource a été supprimée, et si DELETE est appelé à nouveau sur la même ressource, il peut donner un 404 NOT FOUND car la ressource donnée est déjà supprimée.

Voici un exemple de l’endpoint API DELETE du projet e-commerce RESTful.

DELETE /deleteOrder/{id} :  Supprime une commande par ID

Cette API nécessite que le order_id soit fourni comme Paramètre de chemin afin de supprimer la commande respective du système. Aucun corps de requête n’est requis dans cette requête API DELETE. Cependant, en tant que mesure de sécurité, le token doit être fourni comme un en-tête pour supprimer la commande.

Une fois l’API exécutée, elle supprime la commande spécifiée du système et renvoie le code de statut 204.

Dans le cas où la commande n’est pas trouvée, ou si le token n’est pas valide ou n’est pas fourni, elle affichera la réponse suivante :

Comment tester les API DELETE en utilisant Playwright Java

Tester les API DELETE est une étape importante pour garantir la stabilité et la fiabilité de l’application. Une mise en œuvre correcte des API DELETE est essentielle pour vérifier la perte de données non intentionnelle et les incohérences, car les API DELETE sont responsables de la suppression des ressources du système.

Dans cette démonstration de test des API DELETE utilisant Playwright Java, nous utiliserons le /deleteOrder/{id} pour supprimer une commande existante du système.

Scénario de test 1 :  Supprimer une commande valide

1. Démarrer le service de commerce électronique RESTful.
2. À l’aide d’une requête POST, créer des commandes dans le système.
3. Supprimer la commande avec order_id “1” en utilisant la requête DELETE.
4. Vérifier que le code de statut 204 est renvoyé dans la réponse.

Mise en œuvre du test

Les étapes suivantes doivent être exécutées pour mettre en œuvre le scénario de test :

1. Ajoutez de nouvelles commandes en utilisant la requête POST.
2. Appuyez sur l’API /auth pour générer un token.
3. Appuyez sur le point de terminaison de l’API /deleteOrder/ avec le token et le order_id pour supprimer la commande.
4. Vérifiez que le code d’état 204 est retourné dans la réponse.

Une nouvelle méthode de test,  testShouldDeleteTheOrder(), est créée dans la classe de test existante HappyPathTests. Cette méthode de test implémente les trois étapes ci-dessus pour tester l’API DELETE.

@Test

    public void testShouldDeleteTheOrder() {

​

        final APIResponse authResponse = this.request.post("/auth", RequestOptions.create().setData(getCredentials()));

​

        final JSONObject authResponseObject = new JSONObject(authResponse.text());

        final String token = authResponseObject.get("token").toString();

​

        final int orderId = 1;

        final APIResponse response = this.request.delete("/deleteOrder/" + orderId, RequestOptions.create()

                .setHeader("Authorization", token));

        assertEquals(response.status(), 204);

    }

Le point de terminaison de l’API POST /auth sera d’abord appelé pour générer le token. Le token reçu en réponse est stocké dans la variable token pour être utilisé ultérieurement dans la requête API DELETE.

Ensuite, de nouvelles commandes seront générées en utilisant la méthode testShouldCreateNewOrders(), qui a déjà été discutée dans le tutoriel précédent, où nous avons parlé de tester les requêtes POST en utilisant Playwright Java.

Après que les commandes aient été générées, l’étape suivante consiste à effectuer la requête DELETE avec le order_id valide qui supprimerait la commande spécifique.

Nous allons supprimer la commande avec le order_id “1” en utilisant la méthode  delete() fournie par le framework Playwright.

Après la suppression de la commande, le code de statut 204 est renvoyé en réponse. Une assertion sera effectuée sur le code de statut pour vérifier que l’action de suppression a réussi. Comme aucun corps de demande n’est retourné dans la réponse, c’est la seule chose qui peut être vérifiée.

Exécution du test

Nous allons créer un nouveau fichier testng.xml nommé testng-restfulecommerce-deleteorders.xml pour exécuter les tests dans l’ordre des étapes que nous avons discutées dans la mise en œuvre du test.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Restful ECommerce Test Suite">

    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">

        <classes>

            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">

                <methods>

                    <include name="testShouldCreateNewOrders"/>

                    <include name="testShouldDeleteTheOrder"/>

                </methods>

            </class>

        </classes>

    </test>

</suite>

Tout d’abord, la testShouldCreateNewOrders() méthode de test sera exécutée, et elle créera de nouvelles commandes. Ensuite, la testShouldDeleteTheOrder() méthode de test sera exécutée pour tester l’API de suppression de commande.

La capture d’écran suivante de l’exécution du test effectuée à l’aide d’IntelliJ IDE montre que les tests ont été exécutés avec succès.

Maintenant, vérifions que la commande a été correctement supprimée en écrivant un nouveau test qui appellera le point d’API GET /getOrder avec le order_id supprimé.

Scénario de test 2 : Récupérer la commande supprimée

1. Supprimez une commande valide avec order_id “1.”
2. En utilisant l’API GET /getOrder, essayez de récupérer la commande avec order_id “1.”
3. Vérifiez que le code de statut 404 est retourné avec le message “Aucune commande trouvée avec les paramètres donnés !” dans la réponse.

Implémentation du Test

Créons une nouvelle méthode de test, testShouldNotRetrieveDeletedOrder(), dans la classe existante HappyPathTests.

@Test

    public void testShouldNotRetrieveDeletedOrder() {

        final int orderId = 1;

        final APIResponse response = this.request.get("/getOrder", RequestOptions.create().setQueryParam("id", orderId));

​

        assertEquals(response.status(), 404);

​

        final JSONObject jsonObject = new JSONObject(response.text());

        assertEquals(jsonObject.get("message"), "No Order found with the given parameters!");

    }

L’implémentation du test pour ce scénario est assez simple. Nous allons exécuter l’API GET /getOrder pour récupérer la commande supprimée avec order_id “1.”

Une assertion est ensuite appliquée pour vérifier que l’API GET doit retourner le Code de Statut 404 dans la réponse avec le message “Aucune commande trouvée avec les paramètres donnés !”

Ce test garantit que l’API de suppression de commande a bien fonctionné et que la commande a été supprimée du système.

Exécution du Test

Mise à jour du fichier testng.xml et ajoutons ce scénario de test à la fin après le test de suppression.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Restful ECommerce Test Suite">

    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">

        <classes>

            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">

                <methods>

                    <include name="testShouldCreateNewOrders"/>

                    <include name="testShouldDeleteTheOrder"/>

                    <include name="testShouldNotRetrieveDeletedOrder"/>

                </methods>

            </class>

        </classes>

    </test>

</suite>

Maintenant, les trois tests doivent s’exécuter en séquence. Le premier créera des commandes ; le deuxième supprimera la commande avec order_id “1” ; et le dernier test appellera l’API GET pour récupérer la commande avec order_id “1” retournant le Code de Statut 404.

La capture d’écran ci-dessus montre que les trois tests ont été exécutés avec succès, et que l’API DELETE a fonctionné comme prévu.

Résumé

Les requêtes API DELETE permettent la suppression de la ressource du système. Étant donné que la suppression est une fonction CRUD importante, il est essentiel de la tester et de vérifier que le système fonctionne comme prévu. Cependant, il convient de noter que DELETE est un processus irréversible, il doit donc toujours être utilisé avec prudence.

D’après mon expérience, il est judicieux d’appeler l’API GET après avoir exécuté la requête DELETE pour vérifier que la ressource spécifiée a été supprimée avec succès du système.

Bon test !