Passer de Keploy à Apidog CLI

Si votre équipe a commencé avec Keploy, vous aimez probablement une chose à son sujet : vous avez lancé votre application, atteint quelques points de terminaison, et les tests sont apparus. Pas besoin d'écrire des assertions, pas de stubs de dépendances manuels. Keploy capture le trafic réel au niveau du réseau et le rejoue pour vous.

Alors pourquoi quelqu'un voudrait-il se détourner de Keploy ? Habituellement, cela se résume à un besoin différent. Les tests capturés sont excellents pour détecter les régressions de ce qui s'est déjà produit, mais ils sont plus difficiles à lire, à réviser et à prendre en charge au sein d'une équipe. À un certain moment, vous voulez des tests qu'un nouvel ingénieur peut ouvrir dans une pull request, comprendre d'un coup d'œil et modifier intentionnellement. Vous voulez des données de test que vous contrôlez, des environnements que vous basculez avec un flag, et des serveurs de mock que vous concevez plutôt que ceux dérivés d'un enregistrement.

Deux paradigmes différents, comparés honnêtement

Keploy et Apidog se chevauchent sur les mots "test d'API", mais ce sont des catégories d'outils différentes. Prétendre le contraire vous desservirait.

Keploy est une plateforme open source pour créer des bacs à sable de test isolés. Son mouvement signature est l'enregistrement et la relecture : en utilisant eBPF au niveau du réseau, il capture les appels API réels et leurs dépendances (requêtes de base de données, services en aval, événements de streaming) sans SDK et sans modifications de code. À partir de ce trafic capturé, il génère automatiquement des cas de test et des mocks pour ces dépendances. Il dispose également d'un chemin de génération de tests par IA qui construit des suites à partir d'une spécification OpenAPI, d'une collection Postman, d'une commande cURL ou d'un point de terminaison en direct. Parce que la capture se produit au niveau eBPF, elle est agnostique au langage et s'appuie sur Linux et des privilèges élevés. Vous pouvez lire le code source sur GitHub.

Apidog est une plateforme API tout-en-un : conception, débogage, mock, documentation et test en un seul endroit. La CLI Apidog (apidog run) exécute les scénarios de test et les collections que vous avez créés, depuis votre terminal et en CI/CD. Elle prend en charge les tests basés sur les données, le changement d'environnement, plusieurs formats de rapport et les rapports cloud. Apidog dispose également d'une génération de cas de test par IA, mais elle fonctionne à partir de votre schéma API et de vos points de terminaison à l'intérieur de l'application, et non en enregistrant le trafic de production.

Voici la vérité que vous devez connaître avant de planifier quoi que ce soit : Apidog ne capture pas le trafic en direct via eBPF, et il ne génère pas automatiquement des tests en enregistrant les appels de production et les mocks de dépendances. C'est la force distinctive de Keploy. Si la capture d'exécution est au cœur de votre flux de travail, gardez Keploy pour cette tâche. Ce que vous gagnez en passant à Apidog, ce sont des tests conçus, révisables, inter-équipes et une plateforme qui couvre l'ensemble du cycle de vie de l'API.

Lisez ce tableau comme un guide de traduction, pas comme une fiche d'évaluation des fonctionnalités. Chaque capacité de Keploy correspond à une étape de création délibérée dans Apidog. Vous échangez "l'outil l'a compris à partir du trafic" contre "vous avez décrit ce à quoi ressemble la correction".

Étape 1 : Capturez votre surface d'API en tant que spécification

Keploy démarre à partir d'une application en cours d'exécution. Apidog démarre à partir d'une description de votre API. La première tâche consiste donc à obtenir cette description.

Si vous publiez déjà un document OpenAPI, vous avez terminé. Pointez dessus et passez à l'étape suivante. Si ce n'est pas le cas, vous avez plusieurs options, toutes produisant quelque chose d'importable :

• Générez OpenAPI à partir de votre framework (la plupart des frameworks modernes ont un exportateur ou une bibliothèque qui l'émet).
• Exportez une collection Postman si votre équipe en gère déjà une.
• Collectez les commandes cURL que vous utilisez pour atteindre chaque point de terminaison.

Un effet secondaire intéressant : si vous avez des enregistrements Keploy, les requêtes capturées sont un inventaire réel des points de terminaison réellement appelés et avec quelles charges utiles. Utilisez-les comme liste de contrôle pour que votre spécification couvre la même surface, même si vous n'importerez pas les enregistrements eux-mêmes.

Étape 2 : Importez dans Apidog

Téléchargez Apidog, créez un projet et importez votre fichier OpenAPI, votre collection Postman ou vos commandes cURL. Apidog lit la spécification et remplit les points de terminaison, les schémas de requête, les paramètres et les modèles de réponse. Vous disposez maintenant d'une définition structurée de chaque point de terminaison, la même surface que Keploy utilisait, mais sous une forme que vous pouvez modifier, versionner et partager.

C'est aussi le moment où la différence de plateforme apparaît. Ces points de terminaison importés ne sont pas seulement des dispositifs de test. Ce sont de la documentation en direct, des requêtes débogables et la base pour des serveurs de mock, le tout à partir d'une seule importation. Pour une présentation pas à pas de la chaîne d'outils, le guide complet de la CLI Apidog couvre la configuration complète.

Étape 3 : Générez une suite de tests de démarrage, puis créez les scénarios réels

C'est ici que vous retrouvez une partie de la vitesse que vous aimiez chez Keploy. La génération de cas de test par IA d'Apidog lit votre schéma et vos points de terminaison importés et ébauche des cas de test pour vous : requêtes valides, valeurs limites et réponses d'échec courantes basées sur la spécification. C'est un excellent point de départ, et cela vous permet de ne pas partir d'une page blanche. Si vous voulez voir comment cela se compare entre les outils, le résumé des meilleurs générateurs de cas de test par IA le met en contexte.

Deux notes honnêtes. Premièrement, les cas ébauchés par l'IA (dans Apidog ou Keploy) nécessitent un examen humain. Traitez la sortie comme une ébauche, élaguez ce qui ne s'applique pas et resserrez les assertions. Deuxièmement, il s'agit d'une génération à partir d'une spécification, et non à partir du comportement d'exécution, elle ne connaîtra donc pas une particularité qui n'apparaît qu'avec des données de production réelles. C'est exactement le vide que la capture de Keploy comblait, et c'est le vide que vous acceptez lorsque vous passez à des tests conçus.

Ensuite, vous rédigez les scénarios qui comptent. Un scénario enchaîne les requêtes en un flux réel : créer un utilisateur, se connecter avec le jeton renvoyé, récupérer le profil, le mettre à jour, le supprimer. Vous faites des assertions sur les codes de statut, les champs de réponse et la manière dont les données se transmettent d'une étape à l'autre. C'est le travail que Keploy faisait implicitement dans un enregistrement. Le faire explicitement demande plus d'efforts au départ, et cela rapporte chaque fois que quelqu'un lit, révise ou modifie le test par la suite. Le guide sur comment écrire des cas de test avec l'aide de l'IA vous aide à équilibrer la génération et la rédaction manuelle.

Étape 4 : Configurez les environnements et les entrées basées sur les données

Un enregistrement contient un ensemble de valeurs provenant d'une seule exécution. Les tests créés doivent s'exécuter sur n'importe quel environnement avec n'importe quel ensemble de données.

Définissez des environnements dans Apidog (local, staging, production) avec leurs propres URL de base, jetons et variables. Au moment de l'exécution, vous en choisissez un avec -e. Pour les données de test, joignez un fichier CSV ou JSON et Apidog exécute chaque scénario une fois par ligne, de sorte qu'un scénario de connexion couvre une douzaine de combinaisons d'identifiants. Vous pointez vers le fichier avec -d. Le guide de test basé sur les données détaille les formats de fichiers et la liaison des variables.

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -i 123456 \
  -e "staging" \
  -d ./test-data/login-cases.csv

C'est une amélioration concrète par rapport à un enregistrement fixe. Vos données de test sont un fichier que vous possédez, que vous révisez dans les pull requests et que vous étendez à mesure que de nouveaux cas limites apparaissent.

Étape 5 : Exécutez en CI avec apidog run

La commande qui remplace keploy test dans votre pipeline est apidog run. Elle exécute vos scénarios créés, applique l'environnement et le fichier de données choisis, et génère des rapports. Vous pouvez produire une sortie CLI, HTML et JSON, et envoyer les résultats vers le cloud avec --upload-report pour obtenir un lien partageable.

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -i 123456 \
  -e "staging" \
  -r html,cli \
  --upload-report

L'intégration de cela dans votre pipeline est similaire à n'importe quelle étape de test CI : installez la CLI, passez votre jeton et l'ID du scénario, et faites échouer la build en cas de sortie non nulle. Le guide du pipeline CI/CD et le tutoriel GitHub Actions couvrent le YAML exact, et le guide des rapports de test explique comment lire la sortie que votre équipe consultera réellement.

Étape 6 : Créez des serveurs de mock que vous contrôlez

Keploy vous offre des mocks gratuitement en capturant le trafic des dépendances lors de l'enregistrement. Apidog prend l'autre chemin : vous concevez le mock. Puisque vous avez déjà importé votre schéma, Apidog peut générer un serveur de mock à partir de celui-ci, renvoyant des réponses d'exemple réalistes basées sur les types de champs et les règles que vous définissez. Vous décidez de la latence, des cas d'erreur et des charges utiles exactes.

Le compromis est le même que partout ailleurs dans ce guide. Les mocks capturés reflètent ce que vos dépendances ont réellement fait ; les mocks conçus reflètent ce que vous avez décidé qu'elles devraient faire. Pour les tests de contrat et la CI stable, les mocks conçus ont tendance à l'emporter car ils ne dérivent pas avec la production. Si vous voulez des informations plus approfondies, consultez les outils de test de contrat et de mocking et la génération de données de mock à partir de schémas OpenAPI.

Ce que vous gardez et ce que vous abandonnez

Soyez honnête avec votre équipe sur les deux aspects de ce changement.

Vous renoncez à la capture automatique. Pas de keploy record surveillant le trafic réel, pas de mocks de dépendances dérivés des exécutions de production, pas de magie eBPF qui ne nécessite aucun code. Si cette capacité est essentielle pour vous, gardez Keploy dans votre boîte à outils pour cela. Les deux outils peuvent coexister.

Vous gagnez des tests qui ressemblent à de la documentation, des environnements que vous basculez avec un flag, des données de test que vous possédez et révisez, des serveurs de mock que vous concevez, et une plateforme unique pour la conception, le débogage, la documentation et les tests. Le coût est réel (la rédaction demande plus d'efforts que l'enregistrement), et le bénéfice est une maintenabilité que toute votre équipe peut exploiter. L'aperçu plus large des outils d'automatisation des tests d'API replace ces compromis dans leur contexte, et comment tester une API avec Apidog est une bonne lecture pratique à suivre.

Si vous comparez les deux outils côte à côte, la comparaison Apidog vs Keploy détaille les fonctionnalités, et si Keploy ne convient pas spécifiquement à votre équipe, le tour d'horizon des meilleures alternatives à Keploy vaut le détour.

FAQ

Apidog peut-il importer mes enregistrements Keploy existants ? Pas directement. Les enregistrements Keploy sont des captures d'exécution, et Apidog fonctionne à partir de spécifications API. La voie pratique consiste à capturer la surface de votre API en tant qu'OpenAPI (ou Postman/cURL) et à l'importer. Utilisez vos enregistrements Keploy comme liste de contrôle des points de terminaison à couvrir.

Apidog enregistre-t-il le trafic en direct et simule-t-il automatiquement ma base de données comme Keploy ? Non. Apidog ne capture pas le trafic via eBPF et ne génère pas automatiquement de mocks de dépendances à partir d'exécutions réelles. C'est la force distinctive de Keploy. Apidog génère des tests et des mocks à partir de votre schéma, et vous créez des scénarios en plus de cela.

Qu'est-ce qui remplace keploy record et keploy test ? Il n'y a pas d'équivalent à record. Au lieu de cela, vous importez une spécification, générez une suite de démarrage avec l'IA, rédigez des scénarios et les exécutez avec apidog run à la place de keploy test.

Vaut-il la peine de faire l'effort supplémentaire de rédaction pour migrer de Keploy ? Si vous voulez des tests lisibles, révisables dans les pull requests et gérés par toute l'équipe, oui. Si votre besoin principal est la capture sans effort du comportement d'exécution réel, y compris les mocks de dépendances, Keploy le fait toujours mieux, alors gardez-le pour cette tâche.

Puis-je exécuter les deux outils en même temps ? Oui. De nombreuses équipes utilisent Keploy pour les vérifications de régression basées sur la capture et Apidog pour les suites de bout en bout conçues, la documentation et les mocks. Ils résolvent des problèmes différents.

Par où commencer

Choisissez un service. Exportez sa spécification OpenAPI, importez-la dans Apidog, laissez l'IA rédiger quelques cas de test, puis créez un scénario réel avec un environnement et un petit fichier de données. Exécutez-le avec apidog run et intégrez-le à la CI. Une fois que cette boucle vous semble bonne, étendez-vous. Vous échangerez la commodité de l'enregistrement contre des tests que toute votre équipe peut lire, modifier et auxquels elle peut faire confiance. Pour approfondir la CLI elle-même, commencez par le guide d'installation et le tutoriel de test d'API REST en ligne de commande.