Le verdict d'abord
-
Choisissez Postman si vous explorez une API, vous la documentez ou vous partagez des requêtes reproductibles avec des personnes qui n'écriront pas de code de test.
-
Choisissez TestSprite si vous voulez une couverture d'API générée à partir de ce que le service expose réellement, et qui gère la session, l'état, l'ordre d'exécution et le nettoyage en tant que fonctionnalités du produit.
-
Utilisez les deux si votre collection joue un vrai rôle. Gardez-la pour l'exploration et la documentation, et laissez la couverture générée assurer la régression.
Côte à côte
| Critère | Postman | TestSprite |
|---|---|---|
| Point fort principal | Explorer, documenter et partager des requêtes | Générer et maintenir la couverture de ce que le service expose |
| Construction de la couverture | Quelqu'un ajoute chaque requête et écrit les assertions dans un script | Générée à partir d'une spécification ou d'une passe de découverte, puis affinée |
| Gestion des sessions | Des scripts de pré-requête que vous écrivez et maintenez | Auto-Authentication, configurée une seule fois |
| Valeurs entre les appels | Des variables d'environnement définies dans les scripts | Dynamic Variables, alimentées directement par la réponse |
| Ordre d'exécution | L'ordre de la collection, géré à la main | Déduit de ce dont chaque test a besoin et de ce qu'il produit |
| Nettoyage | Ce que vous scriptez vous-même | Auto-Cleanup, lié à ce que l'exécution a créé |
| Usage idéal | Exploration, documentation, vérification manuelle | Étendue de la régression sans QA dédiée |
Le détail de ces quatre mécanismes se trouve dans la documentation sur les tests d'API.
Là où Postman est réellement meilleur
Explorer une API que vous ne connaissez pas. Rien ne vaut le fait de manipuler les endpoints à la main quand vous découvrez encore ce qu'ils font.
Partager une reproduction. Une collection que l'on peut importer et exécuter est le rapport de bug le plus clair qu'une équipe API puisse recevoir.
Une documentation vivante. Des requêtes qui servent aussi d'exemples, conservées au plus près de l'API qu'elles décrivent.
Là où les collections scriptées coûtent cher
Toute collection sérieuse finit par accumuler un ensemble de scripts de pré-requête et de test qui gèrent les tokens, capturent les identifiants, imposent un ordre et font le ménage. C'est un petit framework en JavaScript, enfoui dans un outil qui n'a pas été conçu pour en être un, et que d'ordinaire une seule personne comprend.
Cela fonctionne. Le coût, c'est que la personne qui le comprend devient une dépendance, et que la collection est mise en quarantaine plutôt que réparée lorsqu'elle passe au rouge.
Quand la collection est la documentation
Il existe un cas où une collection remplit une fonction qu'aucune suite générée ne remplace, et qu'il vaut mieux protéger que faire disparaître au nom de la consolidation.
Si votre collection est ce qu'un consommateur externe importe pour apprendre votre API, c'est de la documentation dotée d'un bouton d'exécution, et sa valeur tient à sa lisibilité par quelqu'un qui la découvre. Cela plaide pour la garder courte, soignée et guidée par l'exemple, c'est-à-dire l'inverse de ce qu'attend une suite de régression. Une collection qui a atteint quatre cents requêtes avec une préparation scriptée ne remplit plus ce rôle, et ne le remplit probablement plus depuis un moment.
La séparation nette consiste à laisser la collection jouer le rôle de porte d'entrée et à confier le filet de sécurité à autre chose. Les deux tirent dans des directions opposées, et c'est parce qu'on veut faire porter les deux rôles au même artefact que tant de collections finissent par n'être ni lisibles ni fiables.
Utiliser les deux
Gardez la collection pour l'exploration, la documentation et les reproductions. Laissez la couverture générée prendre en charge les endpoints et les chaînes d'intégration qui doivent continuer à fonctionner. Dans la pratique, les deux se recoupent peu, parce qu'elles répondent à des questions différentes.
Si vous êtes en phase d'évaluation, cassez quelque chose volontairement
Introduisez une vraie régression, par exemple un bouton d'enregistrement qui n'enregistre plus, et observez ce que chaque outil signale. Trois questions : est-ce qu'il échoue, est-ce que l'échec nomme l'écart réel, et est-ce que la personne ou l'agent chargé de la correction peut partir de ce résultat sans avoir à reconstituer toute l'histoire. Un outil qui annonce un succès sur une exécution qui n'a jamais atteint ses assertions a échoué au seul test qui compte.
Connectez le dépôt depuis le tableau de bord et les exécutions partent du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow. Les deux approches sont décrites dans le dépôt CLI.
Ce que TestSprite prend en charge et qu'une collection ne devrait pas porter
L'étendue de la régression, avec les quatre problèmes d'état traités comme des fonctionnalités du produit : Auto-Authentication pour les sessions, Dynamic Variables pour les valeurs qui n'existent qu'à l'exécution, Dependency Chains pour l'ordre, Auto-Cleanup pour ce que l'exécution a créé. Ce sont précisément ces éléments qui transforment une collection en projet de scripting.
La couverture provient d'API Discovery appliqué au service en cours d'exécution, complété par votre spécification, ce qui fait apparaître les chemins d'erreur et les cas limites que les collections écrites à la main laissent de côté. Vous affinez en langage naturel plutôt que dans des scripts de pré-requête.
L'avantage, c'est que votre collection peut redevenir ce qu'elle fait vraiment le mieux : explorer, documenter et fournir à quelqu'un une reproduction qu'il peut importer et exécuter. Plus personne n'a besoin d'être la personne qui comprend le script de rafraîchissement des tokens.
Peut-on importer notre collection ?
Considérez une collection existante comme la spécification de ce qui existe plutôt que comme des tests à migrer. Ce qui est utile, c'est l'inventaire des endpoints.
Newman suffit-il en CI ?
Il exécute très bien des collections en CI. La question n'est pas l'exécuteur, mais plutôt qui maintient les scripts qui gèrent la session, l'état, l'ordre et le nettoyage.
Et les monitors Postman ?
Utiles pour la disponibilité et les vérifications de contrat simples. Ils ne remplacent pas une couverture qui comprend les dépendances entre les appels.
Perdons-nous notre documentation ?
Non. Rien ici ne remplace le rôle de documentation, qui fait partie de ce que Postman réussit le mieux.
Quelle couverture obtient-on dès le premier jour ?
Une passe de découverte accompagnée d'une spécification produit un plan couvrant toute la surface. Relisez-le et retirez les routes d'administration et internes avant de lancer quoi que ce soit.
Gardez la collection pour explorer, pas pour la régression.
Postman est le meilleur endroit pour explorer et documenter une API. Dès qu'une collection devient la suite de régression, la session, les valeurs capturées, l'ordre d'exécution et le nettoyage se transforment en un framework que vous maintenez à la main. Conservez les deux, et laissez chacun faire ce qu'il fait bien.