Maison >interface Web >js tutoriel >Alternative au dramaturge pour les tests d'API

Alternative au dramaturge pour les tests d'API

DDD
DDDoriginal
2024-12-29 15:37:10884parcourir

Playwright Alternative for API Testing
Si vous êtes un SDET qui utilise Playwright pour les tests d'API, vous n'êtes peut-être que trop familier avec les frustrations liées à la gestion des dépendances de bases de données, à la gestion des données et au besoin sans fin de nettoyage. Soyons réalistes : Playwright, bien que fantastique pour les tests d'interface utilisateur, peut s'avérer fastidieux lorsqu'il s'agit de tests d'API. Mais et s’il existait une meilleure façon de gérer cela ?

Dans cet article, je vais vous montrer comment passer à Keploy, un outil de test d'API open source et la meilleure alternative aux dramaturges en matière de tests d'API et d'API simulées. Si vous souhaitez rationaliser votre processus de test et éliminer les problèmes liés aux bases de données, restez dans les parages. Cette migration pourrait changer la donne que vous attendiez.

Présentation du dramaturge pour les tests d'API

Playwright Test a été créé spécifiquement pour répondre aux besoins des tests de bout en bout. Il est populaire pour automatiser les interactions avec les navigateurs et a étendu ses capacités aux tests d’API. Les fonctionnalités de test d'API de Playwright vous permettent d'effectuer des requêtes HTTP, de valider des réponses et même de simuler des points de terminaison. Mais lorsque vous comptez sur Playwright pour tester des API dans des environnements complexes, les défis s'additionnent rapidement.

Bien que Playwright soit un outil solide, voici quelques-unes des raisons pour lesquelles j'ai rencontré des problèmes :

  • Configuration manuelle des simulations : avec Playwright, vous devez définir manuellement des réponses simulées pour chaque interaction API. Cela implique de configurer des routes avec page.route() ou d'intercepter les requêtes réseau à l'aide de luminaires, ce qui peut devenir répétitif et sujet aux erreurs. Pour les applications volumineuses comportant de nombreux points de terminaison, cela entraîne une quantité importante de code qui doit être gérée et maintenue.

  • La couverture peut ne pas être complète : étant donné que Playwright se concentre principalement sur les tests de bout en bout et la simulation des interactions des utilisateurs, il est possible que seul le code de l'interface utilisateur soit testé et la logique sous-jacente ( Les appels API, le traitement backend) peuvent ne pas être entièrement couverts.

  • Surcharge de configuration des tests : La configuration d'un environnement de test dans Playwright, en particulier lorsque l'on se moque des appels d'API, prend beaucoup de temps. Comme cette configuration implique la configuration d'itinéraires, de réponses et de données, elle nécessite du temps et des efforts supplémentaires avant même d'exécuter les tests proprement dits.

  • Tests lents : La simulation manuelle des réponses d'API dans Playwright implique souvent la configuration d'un grand nombre de simulations pour différents points de terminaison et réponses. Cela ajoute au temps d'exécution, car chaque test doit passer par plusieurs interactions simulées, et la gestion d'un nombre important de simulations peut ralentir le processus, en particulier pour les grandes suites de tests.

  • Intégration limitée avec Backend Logic : Playwright est conçu pour se concentrer sur les interactions du navigateur, et non sur les tests API ou côté serveur. Par conséquent, si vous testez des interactions qui reposent sur des API ou des services backend, cela ne vous permet pas naturellement de savoir si votre code backend est entièrement couvert.

  • Problèmes d'isolation des tests : les tests de dramaturge nécessitent souvent des données réelles ou simulées, et la mise en place d'une isolation de test appropriée peut être délicate, en particulier lorsque l'on s'appuie sur des bases de données externes, des services ou des API tierces.

Au fur et à mesure que ces problèmes augmentaient, j'ai commencé à chercher une solution qui pourrait rendre les tests d'API plus simples et plus efficaces. C'est là que Keploy est entré en scène.

Pourquoi migrer vers Keploy ?

Keploy est un excellent outil pour les tests d'API qui aide également à créer des simulations/stubs de données. Contrairement à Playwright, qui nécessite souvent des configurations complexes pour la gestion de bases de données et la création de données de test, Keploy automatise bon nombre de ces processus. Voici pourquoi migrer vers Keploy était logique pour moi :

  1. Plus de configuration manuelle des simulations

    Keploy élimine le travail pénible d'écriture de code de test API répétitif. Au lieu de définir manuellement les requêtes, les réponses et les données fictives, Keploy capture les interactions réelles avec l'API et vous permet de les rejouer plus tard. Cela élimine le besoin d'un code de test étendu et réduit considérablement le temps consacré à la création des tests.

  2. Aucune dépendance à la base de données

    Keploy enregistre les interactions API réelles et les rejoue pour de futures exécutions de tests, ce qui signifie que vous n'avez plus besoin d'une base de données active pour exécuter les tests. Cela élimine les frais liés à la maintenance d'une base de données en cours d'exécution et à son nettoyage après chaque test.

  3. Plus rapide*Exécution des tests plus rapide*

    Étant donné que Keploy ne nécessite pas la configuration ou la suppression d'une base de données, l'exécution des tests devient beaucoup plus rapide. Avec les tests déjà enregistrés, la nécessité de préparer des données de test ou d'interagir avec des bases de données appartient au passé.

  4. Intégration facile avec CI/CD

    Keploy s'intègre parfaitement aux pipelines CI/CD, fournissant un retour d'information plus rapide et améliorant la productivité globale. Vous pouvez facilement exécuter des tests API enregistrés dans le cadre de votre processus d'intégration continue sans vous soucier des états de la base de données ou de la configuration manuelle des tests.

  5. Couverture complète des tests

    Étant donné que Keploy enregistre les interactions API du monde réel, vous pouvez obtenir une couverture de test plus précise et plus complète. En rejouant ces interactions enregistrées, Keploy peut simuler des cas extrêmes du monde réel qui peuvent ne pas être entièrement capturés avec des tests écrits manuellement.

Étapes pour migrer de Playwright vers Keploy

Nous exécuterons une application simple de gestion des utilisateurs dans NextJS avec Postgres comme base de données pour ce guide.

Étape 1 : Évaluez votre configuration actuelle de test d'API

Avant de me lancer dans la migration, j'ai d'abord évalué les tests API existants que j'avais écrits dans Playwright. Cela comprenait :

  • Examen de toutes les requêtes et réponses API que je testais.

  • Documenter la configuration requise pour chaque test (comme l'état de la base de données et les données fictives).

  • Exécuter une suite de tests complète pour vérifier les problèmes existants et collecter des données de couverture de test.

Le test de dramaturge pour ma candidature est présent dans app.spec.ts sous le dossier test.

import { test, expect } from '@playwright/test';

const apiUrl = 'http://localhost:3000/api/users';  // Application is running on port 3000

test.describe('User API Tests', () => {

    // Test GET request (Fetch all users)
    test('GET /api/users should return a list of all users', async ({ request }) => {
        const response = await request.get(apiUrl);
        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users).toBeInstanceOf(Array);
    });    
});

Une fois que j'ai eu une compréhension claire de ma situation actuelle en matière de tests, il était temps de passer à l'action.

Étape 2 : Installez Keploy et configurez l'environnement

L'étape suivante consistait à installer Keploy dans mon environnement de test. Le processus d'installation de Keploy est simple et direct, avec des instructions détaillées disponibles dans le référentiel Keploy GitHub. Après l'installation, nous pouvons vérifier la configuration en effectuant une vérification rapide dans le terminal :

Playwright Alternative for API Testing

Cela a confirmé que Keploy était correctement installé et prêt à fonctionner.

Étape 3 : Enregistrez les interactions API avec Keploy

Keploy fonctionne en enregistrant les interactions API réelles qui se produisent pendant l'exécution des tests. Pour capturer ces interactions, nous devons exécuter mes tests Playwright comme d'habitude, mais cette fois avec Keploy en mode d'enregistrement. Voici comment je l'ai configuré :

  1. Démarrez votre application et votre base de données à l'aide de Docker Compose ou d'une autre configuration.

  2. Exécutez Keploy en mode d'enregistrement pour capturer de véritables interactions API :

keploy record -c "npm run dev"

Cette commande a demandé à Keploy de capturer toutes les requêtes et réponses HTTP générées par les tests Playwright.

Playwright Alternative for API Testing

Lançons notre suite de tests de dramaturge -

Playwright Alternative for API Testing

Nous pouvons remarquer que Keploy enregistre chacun des cas de test qui faisaient partie de la suite de tests existante écrite dans Playwright.

Playwright Alternative for API Testing

Chacun des cas de test générés par Keploy est un cas de test Playwrigth : –

test('POST /api/users should create a new user', async ({ request }) => {
        const newUser = {
            name: 'John Do',
            email: 'johndoee@xyz.com'
        };

        const response = await request.post(apiUrl, {
            data: newUser
        });

        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users[0]).toHaveProperty('id');  // Check if the first user in the array has an ID
        expect(body.users[0].name).toBe(newUser.name);
        expect(body.users[0].email).toBe(newUser.email);
    });


    // Test PUT request (Update an existing user)
    test('PUT /api/users should update an existing user', async ({ request }) => {
        // First, create a new user to update
        const newUser = {
            name: 'Jane Doe',
            email: 'janedoe@example.com'
        };

        let response = await request.post(apiUrl, {
            data: newUser
        });

        // Check if the POST request was successful
        expect(response.status()).toBe(200); // Ensure status code is 200
        const createdUser = await response.json();
        expect(createdUser.users).toHaveLength(1);
        const userId = createdUser.users[0].id;

        // Prepare the updated user data
        const updatedUser = {
            id: userId,
            name: 'John Deo',
            email: 'updated@example.com'
        };

        // Make the PUT request to update the user
        response = await request.put(apiUrl, {
            data: updatedUser
        });

        // Check if the PUT request was successful
        expect(response.status()).toBe(200);
        const body = await response.json();

        // Check if the updated fields match the new values
        expect(body.users[0].name).toBe(updatedUser.name);
        expect(body.users[0].email).toBe(updatedUser.email);
    });    

    // Test DELETE request (Delete a user)
    test('DELETE /api/users should delete a user', async ({ request }) => {
        // First, create a user to delete
        const newUser = {
            name: 'Mark Doe',
            email: 'markdoe@example.com'
        };

        let response = await request.post(apiUrl, {
            data: newUser
        });

        // Check if the response body is empty or invalid
        if (!response.ok()) {
            console.error('Failed to create user', await response.text());
            expect(response.ok()).toBe(true);  // Fail the test if the response is not OK
        }

        const createdUser = await response.json();
        if (!createdUser || !createdUser.users || createdUser.users.length === 0) {
            console.error('Invalid response format:', createdUser);
            throw new Error('Created user response format is invalid');
        }

        const userId = createdUser.users[0].id;  // Accessing the ID of the newly created user

        // Delete the created user
        response = await request.delete(apiUrl, {
            data: { id: userId }  // Sending the ID of the user to be deleted
        });

        // Check if the delete response is valid
        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users[0].id).toBe(userId);  // Ensure the correct user is deleted
    });

Étape 4 : Rejouer les interactions enregistrées sous forme de tests

Une fois les interactions enregistrées, Keploy a généré automatiquement les cas de tests correspondants. Vous trouverez ci-dessous l'un de ces cas de test Keploy : –

Playwright Alternative for API Testing

Ces tests peuvent être exécutés indépendamment sans avoir besoin de dépendances externes comme une base de données en direct. Tout ce que j'avais à faire était d'exécuter la suite de tests de Keploy :

import { test, expect } from '@playwright/test';

const apiUrl = 'http://localhost:3000/api/users';  // Application is running on port 3000

test.describe('User API Tests', () => {

    // Test GET request (Fetch all users)
    test('GET /api/users should return a list of all users', async ({ request }) => {
        const response = await request.get(apiUrl);
        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users).toBeInstanceOf(Array);
    });    
});

Cette commande déclenchait la lecture des interactions enregistrées, testant l'API sans avoir besoin d'une véritable base de données.

Playwright Alternative for API Testing

Conclusion

La migration de Playwright vers Keploy a changé la donne pour mon processus de test d'API. Voici un bref récapitulatif des raisons pour lesquelles Keploy est bien mieux adapté aux tests d'API modernes :

  • Plus de problèmes de base de données : Keploy élimine le besoin d'une base de données en direct, ce qui rend vos tests plus rapides et plus faciles à gérer.

  • Tests zéro code : Fini le code de test répétitif : Keploy automatise tout, de la simulation de données à la génération de tests.

  • Intégration CI/CD transparente : Keploy s'intègre parfaitement dans les pipelines CI/CD existants, accélérant votre cycle de feedback et augmentant la productivité.

  • Couverture réaliste des tests : Keploy capture les interactions réelles de l'API, garantissant une couverture complète des tests et des résultats fiables.

Si vous rencontrez des difficultés avec la complexité de Playwright pour les tests d'API, je vous recommande fortement d'essayer Keploy. Il s'agit d'un moyen simple, puissant et efficace d'automatiser vos tests d'API, vous permettant de vous concentrer sur la création de logiciels de haute qualité au lieu de vous soucier de la configuration de l'infrastructure et de la gestion des données.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn