Tests d'API en Python : de requests et pytest à une suite qui tient dans la durée

Là où commencent généralement les tests d'API en Python, et pourquoi c'est très bien ainsi

Ne laissez personne vous détourner de requests et pytest. Les tests sont du Python ordinaire, les fixtures se composent, parametrize couvre proprement les valeurs limites, et toute l'équipe sait les lire. Pour une suite ciblée autour d'un service dont vous êtes responsable, cela reste une excellente réponse.

Les quatre éléments qui finissent par devenir du travail

• Les sessions. Une fixture de token fonctionne jusqu'à ce qu'il expire en pleine exécution ; vous écrivez alors une logique de renouvellement et vous la mettez en cache entre les workers.

• Les valeurs capturées. Un identifiant issu d'un appel alimente le suivant. Les fixtures s'en chargent jusqu'à ce que le graphe s'élargisse, et c'est alors le graphe de fixtures que vous maintenez.

• L'ordre d'exécution. pytest n'ordonne pas les tests selon leurs dépendances. Les équipes se tournent vers des plugins d'ordonnancement, et un seul échec précoce produit un écran entier de rouge sans rapport.

Le quatrième, c'est le nettoyage en parallélisme. Dès que pytest-xdist entre en jeu, supprimer par motif de nom n'est plus sûr, et le teardown doit savoir exactement ce que chaque exécution a créé.

Le vrai coût

Aucun de ces points n'est difficile isolément. Ensemble, ils forment un framework maison : un conftest auquel personne ne veut toucher, un graphe de fixtures qu'une seule personne comprend, et une suite que l'on met en quarantaine plutôt que de la réparer quand elle passe au rouge. Ce scénario est assez fréquent pour qu'on l'anticipe.

Ce qu'une couche dédiée prend en charge

Quatre éléments déterminent si une suite d'API survit à sa première année, quel que soit l'outil utilisé : les sessions qui expirent, les valeurs qui n'existent qu'à l'exécution, les appels qui dépendent les uns des autres, et les enregistrements que personne ne nettoie. TestSprite les nomme Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, et la documentation sur les tests d'API en détaille le fonctionnement.

La couverture vient elle aussi d'ailleurs. Plutôt que les endpoints dont quelqu'un s'est souvenu, un plan généré à partir d'une spécification ou d'une passe de découverte sur le service en fonctionnement inclut les chemins d'erreur et les cas limites que personne n'écrit jamais à la main.

Si vous voulez les tests dans votre dépôt

Certaines équipes veulent que la suite vive dans le dépôt et soit relue comme n'importe quel autre code, et c'est une préférence légitime. Le CLI prend en charge des tests backend écrits en Python, avec des dépendances déclarées test par test et un teardown marqué comme cas à part entière : le graphe est ainsi explicite au lieu d'être implicite dans l'imbrication des fixtures. Les détails se trouvent dans le dépôt du CLI.

Le conftest qui a dévoré l'équipe

Une suite Python devenue trop grosse pour elle-même a une forme reconnaissable, et elle tient dans un seul fichier. Le conftest commence par une fixture de session et une URL de base. Puis une fixture de token, puis un cache pour ne pas récupérer le token à chaque test, puis un verrou parce que les workers xdist se marchaient dessus sur ce cache. Puis des factories, puis un registre pour que le teardown sache quoi supprimer, puis des marqueurs d'ordre parce que certaines factories dépendent d'autres.

Chaque étape est correcte isolément, et le résultat fait six cents lignes qu'une seule personne comprend. Le signe qui ne trompe pas : quelqu'un signale un test en échec et la première question est de savoir si le conftest a changé.

Cela mérite d'être nommé, car la décision de le construire n'est jamais prise. Il s'accumule. Décider tôt quelles parties vous comptez assumer, et lesquelles vous préférez éviter, coûte moins cher que de découvrir la réponse au neuvième mois.

Exécutez-la là où le code change

Une suite Python qui s'exécute avant les releases détecte les problèmes tard. L'exécuter à chaque pull request, voilà le changement qui compte.

Deux voies possibles, et le choix porte en réalité sur qui est responsable du pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, car elle réagit au déploiement que votre build produit déjà. Ajouter une étape GitHub Actions place la vérification dans le dépôt, où elle est relue comme le reste du build.

Ce que TestSprite prend en charge à votre place

Les quatre éléments qui transforment une suite pytest en infrastructure sont traités comme un produit. Auto-Authentication obtient et renouvelle les sessions par environnement. Dynamic Variables transporte un identifiant d'une réponse vers la requête suivante. Dependency Chains déduit l'ordre d'exécution de ce que chaque cas exige et produit, de sorte qu'un échec fait sauter ses dépendants au lieu de les faire échouer. Auto-Cleanup supprime exactement ce qu'une exécution a créé, ce qui rend l'exécution parallèle sûre.

La couverture arrive elle aussi par une autre voie. API Discovery énumère les endpoints réellement exposés par le service en fonctionnement, et les plans générés incluent les chemins d'erreur et les valeurs limites que personne n'écrit en fin de sprint.

Vous obtenez une suite que personne n'a peur de modifier, sans conftest que seule une personne comprend. Gardez pytest pour les tests unitaires et de logique, où il est vraiment le meilleur outil ; la question ici est de savoir où réside l'étendue de la couverture.