Tests API : Liste de vérification et autotests

Checklist de test d'API : des codes d'état à l'automatisation pilotée par l'IA

Le test d'API exige une approche méthodique : valider les codes d'état, la structure des réponses, les cas limites et l'authentification. Postman excelle pour les tests manuels, tandis que Jest + axios s'intègre parfaitement aux pipelines CI/CD. L'IA accélère la génération de cas de test à partir des spécifications OpenAPI, analyse les réponses et repère les motifs de données atypiques.

Catégories clés du test d'API

Le test d'API couvre plusieurs domaines essentiels. Omettre l’un d’eux expose à des bugs non détectés en production.

Codes d’état

Vérifiez que le code correspond au scénario attendu :

| Scénario | Code attendu |

|----------|---------------|

| Création réussie | 201 |

| Ressource introuvable | 404 |

| Permissions insuffisantes | 403 |

| Non authentifié | 401 |

| Données invalides | 400/422 |

| Erreur serveur | 500 |

Piège courant : renvoyer un 200 avec une erreur dans le corps — cela viole les principes REST.

Structure de la réponse

• Les champs obligatoires sont présents.
• Les types de données correspondent aux attentes (ex. nombre au lieu de chaîne).
• Les objets imbriqués ne sont pas nuls.
• Les tableaux ne sont pas confondus avec des objets.

Cas limites

Testez les conditions extrêmes :

• Corps de requête vide.
• Champ requis manquant.
• Chaîne vide dans un champ.
• Nombres : 0, valeurs négatives, MAX_INT.
• Chaînes : 1 caractère, longueur maximale, caractères spéciaux, charges SQL/XSS.

Authentification et en-têtes

• Pas de jeton : 401.
• Jeton expiré : 401.
• Jeton invalide : 403.
• Utilisateur en lecture seule sur opération d’écriture : 403.

En-têtes : Content-Type, CORS, limitation de débit.

Test avec Postman

Utilisez l’onglet Tests pour écrire des scripts JavaScript après avoir reçu une réponse.

Assertions basiques

// Statut et temps de réponse
pm.test("Statut 200", () => {
    pm.response.to.have.status(200);
});

pm.test("Réponse <500ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

// Type de contenu
pm.test("JSON", () => {
    pm.response.to.have.header("Content-Type", "application/json; charset=utf-8");
});

Structure et types

const response = pm.response.json();

pm.test("id présent", () => {
    pm.expect(response).to.have.property("id");
});

pm.test("id est un nombre", () => {
    pm.expect(response.id).to.be.a("number");
});

pm.test("email non vide", () => {
    pm.expect(response.email).to.be.a("string").and.not.empty;
});

Cas négatifs : absence de jeton

pm.test("401 sans jeton", () => {
    pm.response.to.have.status(401);
});

const response = pm.response.json();
pm.expect(response).to.have.property("message");

Sauvegardez le jeton issu de /login dans une variable d’environnement : pm.environment.set("auth_token", response.token);. Référez-vous-y comme {{auth_token}} dans les en-têtes.

Tests automatisés avec Jest + axios

Pour les pipelines CI/CD, écrivez les tests directement dans le code. Exemple pour /users/:id :

const axios = require("axios");

const BASE_URL = "https://api.example.com";
const TOKEN = process.env.API_TOKEN;

const client = axios.create({
    baseURL: BASE_URL,
    headers: { Authorization: `Bearer ${TOKEN}` }
});

describe("GET /users/:id", () => {

    test("Récupérer un utilisateur par ID", async () => {
        const response = await client.get("/users/1");

        expect(response.status).toBe(200);
        expect(response.data).toMatchObject({
            id: expect.any(Number),
            email: expect.any(String),
            name: expect.any(String),
        });
    });

    test("404 pour utilisateur inconnu", async () => {
        await expect(client.get("/users/999999"))
            .rejects.toMatchObject({
                response: { status: 404 }
            });
    });

    test("401 sans jeton", async () => {
        await expect(axios.get(`${BASE_URL}/users/1`))
            .rejects.toMatchObject({
                response: { status: 401 }
            });
    });

});

Exécutez avec : npx jest user.test.js.

Checkliste universelle

Scénarios positifs :

• Données valides → statut correct.
• Structure de réponse conforme à la documentation.
• Champs obligatoires présents.
• Types de données corrects.
• Temps de réponse dans les limites acceptables.

Cas négatifs :

• Pas d’auth → 401.
• Jeton erroné → 403.
• Champ manquant → 400/422.
• Type incorrect → 400/422.
• Ressource inexistante → 404.
• Corps vide → erreur de validation.

Cas limites :

• Valeurs minimales/maximales.
• Nombres zéro ou négatifs.
• Chaînes vides.
• Caractères spéciaux/Unicode.
• Chaînes longues.

Sécurité :

• Injection SQL.
• XSS.
• IDOR (devinette d’ID).

Automatisation pilotée par l’IA

L’IA génère automatiquement des cas de test à partir des spécifications OpenAPI — positifs, négatifs et limites — au format Jest.

Prompt : « Générer des tests pour POST /users selon le schéma [schema]. Utiliser des données réalistes. »

Analyse automatique des réponses via LLM :

async function validateWithAI(prompt, response) {
    // Appel à Claude/GPT pour évaluer la pertinence
    // ...
    return data.content[0].text.trim() === "YES";
}

Génération de données limites : l’IA propose du texte RTL, des emojis, des caractères Unicode invisibles.

L’IA ne remplace pas la compréhension du métier (ex. remise ≤ 100 pour les utilisateurs non premium).

Ce qui compte vraiment

• Validez strictement les codes d’état selon le scénario — jamais de 200 pour une erreur.
• Testez la structure et les types de réponse avec des assertions similaires à JSONPath.
• Automatisez les cas négatifs et limites dans CI/CD avec Jest/axios.
• Utilisez l’IA pour les tâches répétitives : génération de tests, analyse, données limites.
• Appliquez la checkliste comme modèle obligatoire pour chaque endpoint.

— Editorial Team