Si vous avez cherché un moyen d'obtenir des tests d'API sans les écrire à la main, vous avez probablement rencontré Keploy. Il promet quelque chose qui semble presque trop pratique : le pointer vers votre application en cours d'exécution, le laisser observer le trafic réel, et repartir avec une suite de tests. Alors, que fait réellement Keploy en coulisses, et où se situe-t-il dans votre pile de tests ?
Ce guide explique ce qu'est Keploy, comment son moteur d'enregistrement et de relecture fonctionne au niveau de la couche réseau eBPF, les deux workflows qu'il offre, comment l'installer et l'exécuter, et les limites honnêtes que vous devriez connaître avant de l'adopter.
Qu'est-ce que Keploy ?
Keploy est une plateforme open source (sous licence Apache-2.0) pour créer des environnements sandbox de production sûrs et isolés pour les tests d'API, d'intégration et de bout en bout. L'idée principale est que votre application réelle exerce déjà le comportement que vous souhaitez tester. Au lieu de vous demander de décrire ce comportement dans le code de test, Keploy l'observe et le transforme en tests reproductibles.
Il vous offre deux façons de le faire :
- Enregistrement et relecture capture les interactions API réelles et leurs dépendances, puis les rejoue de manière déterministe.
- Génération de tests par IA construit des suites de tests API validées à partir d'une spécification, d'une collection, d'une commande cURL ou d'un point de terminaison en direct.
Les deux produisent des tests exécutables ainsi que les mocks nécessaires pour les exécuter sans toucher aux dépendances réelles. Le projet est open source, vous pouvez donc lire le code et l'auto-héberger. Le dépôt se trouve sur github.com/keploy/keploy, et la documentation officielle est sur keploy.io/docs.
Comment Keploy record fonctionne au niveau de la couche eBPF
C'est ce qui rend Keploy distinct. Lorsque vous exécutez keploy record, il ne vous demande pas d'ajouter un SDK ni de modifier une seule ligne de code de votre application. Il capture le trafic au niveau de la couche réseau en utilisant eBPF, une technologie du noyau Linux qui permet aux programmes d'observer et d'agir en toute sécurité sur les événements système.
Voici ce que cela vous apporte en pratique :
- Capture sans code. Pas d'instrumentation, pas de harnais de test, pas de décorateurs dans vos gestionnaires. Keploy se situe en dessous de votre application et observe les octets entrants et sortants.
- Capture agnostique du langage. Parce que la capture se fait au niveau de la couche réseau du noyau plutôt qu'à l'intérieur d'un runtime, elle fonctionne de la même manière, que votre service soit écrit en Go, Python ou Rust.
- Capture des dépendances. Keploy n'enregistre pas seulement l'appel API entrant et sa réponse. Il enregistre également les appels sortants que votre service effectue vers ses dépendances, comme les requêtes de base de données et les événements réseau ou de streaming.
Ce dernier point est important. Lorsque Keploy enregistre une requête, il capture l'image complète : la requête API, la réponse API et chaque appel de dépendance qui s'est produit entre les deux. Il écrit ensuite deux artefacts à partir de cette interaction unique observée :
- Un cas de test décrivant la requête et la réponse attendues.
- Des mocks et stubs pour chaque appel de dépendance, afin que le test puisse être rejoué sans base de données ou service en aval en direct.
La relecture boucle la boucle. Lorsque vous exécutez keploy test, il renvoie les requêtes enregistrées à votre application, sert les réponses de dépendance capturées à partir des mocks générés et compare les nouvelles réponses aux réponses enregistrées. Une non-concordance signifie que quelque chose a changé. C'est pourquoi l'approche est appelée enregistrement et relecture : vous enregistrez un comportement d'exécution réel une fois, puis vous le rejouez de manière déterministe en tant que test de régression à chaque changement.
Les deux workflows Keploy
Enregistrement et relecture
Utilisez ceci lorsque vous avez déjà une application fonctionnelle et que vous souhaitez rapidement une couverture de régression. Vous exécutez l'application sous Keploy, l'utilisez comme le ferait un utilisateur ou un client réel (appels manuels, un test d'intégration existant ou du trafic réel), et Keploy enregistre chaque interaction comme un test plus ses mocks. Les exécutions ultérieures rejouent ces interactions et signalent toute dérive comportementale.
Génération de tests par IA
Utilisez ceci lorsque vous souhaitez une couverture plus large que celle produite par votre exercice manuel, ou lorsque vous partez d'un contrat plutôt que d'un flux en cours d'exécution. Keploy peut générer des suites de tests API validées à partir d'une spécification OpenAPI, d'une collection Postman, d'une commande cURL ou d'un point de terminaison en direct. Il simule automatiquement les dépendances et exécute un passage de nettoyage automatique afin de ne pas vous laisser avec des cas redondants.
Les deux workflows sont complémentaires. L'enregistrement et la relecture ancrent les tests dans un comportement réel observé ; la génération de tests par IA comble les lacunes de votre spécification. Si vous évaluez des outils qui génèrent des tests à partir d'un schéma, notre tour d'horizon des générateurs de cas de test IA et le guide pour générer des scripts de test à partir d'OpenAPI sont de bons compléments.
Installation de Keploy
Keploy propose un script d'installation. Sur un système pris en charge, vous exécutez :
curl --silent -O -L https://keploy.io/install.sh && source install.sh
Cela télécharge le binaire et configure la commande keploy. À partir de là, vous pilotez tout via deux commandes.
Les commandes Keploy principales
Il y a deux commandes que vous utiliserez le plus. La première enregistre :
keploy record -c "CMD_TO_RUN_APP"
Vous passez la commande exacte qui démarre votre application via -c. Keploy lance votre application, surveille le trafic pendant que vous l'utilisez, et enregistre les cas de test capturés et les mocks.
La seconde rejoue :
keploy test -c "CMD_TO_RUN_APP" --delay 10
L'option --delay 10 indique à Keploy d'attendre dix secondes avant de commencer à envoyer les requêtes enregistrées, ce qui donne à un service plus lent suffisamment de temps pour finir de démarrer avant que la relecture ne commence. Si votre application a besoin de plus de temps pour démarrer, augmentez le nombre ; si elle démarre rapidement, vous pouvez le réduire.
Une première session typique ressemble à ceci :
# 1. Enregistrer pendant que vous accédez à votre API
keploy record -c "node server.js"
# 2. Rejouer les cas capturés et vérifier les dérives
keploy test -c "node server.js" --delay 10
C'est la boucle complète. Enregistrez une fois contre une version stable connue, puis exécutez keploy test en CI à chaque changement.
Langages, protocoles et magasins de données pris en charge
Parce que la capture se fait au niveau de la couche réseau, Keploy couvre une large surface :
| Catégorie | Pris en charge |
|---|---|
| Langages | Go, Java, Node.js, Python, Rust, C#, C/C++, TypeScript, et plus |
| Protocoles | HTTP/REST, gRPC, GraphQL, Kafka, RabbitMQ |
| Magasins de données | PostgreSQL, MySQL, MongoDB, Redis |
L'étendue est une conséquence directe de la conception eBPF. Keploy lit les conversations réseau, donc un nouveau langage ou framework n'a pas besoin d'un nouveau plugin tant qu'il parle l'un de ces protocoles.
Exécuter Keploy en CI
Les deux commandes sont conçues pour l'automatisation. Dans un pipeline, vous commitez les cas de test et les mocks enregistrés avec votre code, puis vous exécutez keploy test -c "..." comme une étape. Parce que les mocks remplacent les dépendances réelles, la relecture n'a pas besoin d'une base de données ou d'un service en aval en direct dans le runner CI, ce qui rend le travail rapide et déterministe. Une relecture échouée fait échouer la build, de la même manière qu'un test unitaire.
Limitations honnêtes à considérer
Keploy est puissant dans ce qu'il fait, mais il ne convient pas à toutes les situations. Une évaluation juste inclut les compromis :
- Il penche vers Linux et les privilèges élevés. eBPF est une fonctionnalité du noyau Linux, et la capture à ce niveau nécessite généralement des autorisations élevées. Cela détermine où et comment vous pouvez l'exécuter.
- Les tests générés nécessitent une curation. Les tests construits à partir de trafic réel ou de génération par IA sont un point de départ, pas une suite finie. Vous devez toujours les examiner, supprimer le bruit et décider quels comportements capturés sont réellement des contrats qui méritent d'être appliqués.
- C'est un outil de test et de génération de tests, pas une plateforme complète de cycle de vie des API. Keploy se concentre sur la capture, la génération et la relecture des tests. Il n'est pas conçu pour gérer la conception d'API, la documentation, la publication de serveurs mock pour les consommateurs, ou la collaboration d'équipe autour d'une spécification d'API.
Aucun de ces points n'est une critique contre Keploy. Ce sont les limites naturelles de sa catégorie. Les connaître vous aide à décider s'il résout votre problème ou seulement une partie de celui-ci.
Où Apidog s'insère comme alternative de test conçue
Si votre besoin est plus large que « transformer le trafic observé en tests de régression », il vaut la peine d'examiner une plateforme complète de cycle de vie. Apidog est une plateforme API tout-en-un qui couvre la conception, le débogage, le mocking, la documentation et les tests en un seul endroit. La différence de philosophie est la clé à comprendre, car Apidog et Keploy se situent dans des catégories différentes.
Keploy capture et rejoue le comportement d'exécution réel, y compris les mocks de dépendance, sans code. Apidog prend le chemin inverse : vous concevez et rédigez des scénarios de test maintenables, puis vous les exécutez depuis le terminal et la CI avec la CLI Apidog. La CLI exécute vos collections rédigées avec des tests basés sur les données via CSV ou JSON, la commutation d'environnement et des rapports CLI, HTML et JSON. Apidog propose également la génération de cas de test par IA à partir de votre schéma d'API et de vos points de terminaison, rédigés à l'intérieur de l'application, ce qui est là où les deux outils se recoupent.
Pour être clair sur la limite : 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épendance. Cette capacité d'enregistrement à partir de trafic réel est authentiquement celle de Keploy. Le cadre honnête est que vous choisissez en fonction de la tâche. Optez pour Keploy lorsque vous souhaitez la capture et la relecture d'exécution avec zéro code. Optez pour Apidog lorsque vous souhaitez des suites de tests conçues et maintenables au sein d'une plateforme qui gère également le reste du cycle de vie de l'API. Pour une comparaison plus approfondie, consultez Apidog vs Keploy, et si vous avez décidé de changer, le guide de migration couvre le déplacement de vos tests.
Si des tests d'API maintenables et rédigés sont ce que vous recherchez, vous pouvez télécharger Apidog et commencer avec le guide pour tester une API avec Apidog.
Questions fréquemment posées
Keploy est-il gratuit et open source ? Oui. Keploy est open source sous la licence Apache-2.0, et le code est sur GitHub. Vous pouvez l'auto-héberger.
Keploy nécessite-t-il de modifier le code de mon application ? Non. Le workflow d'enregistrement et de relecture capture le trafic au niveau de la couche réseau eBPF, il n'y a donc pas de SDK à ajouter et aucune modification de code. C'est aussi pourquoi il fonctionne avec de nombreux langages.
Que fait l'option --delay dans keploy test ? Elle définit le nombre de secondes que Keploy attend avant d'envoyer les requêtes enregistrées, donnant à votre application le temps de démarrer. --delay 10 attend dix secondes ; augmentez-le pour les services qui démarrent lentement.
Keploy peut-il simuler ma base de données pendant les tests ? Oui. Lorsqu'il enregistre une interaction, il capture également les appels de dépendance (tels que les requêtes de base de données) et écrit des mocks pour eux, de sorte que les relectures s'exécutent sans base de données en direct.
Keploy est-il un remplacement pour un outil de conception et de documentation d'API ? Non. Keploy est un outil de test et de génération de tests. Pour la conception d'API, la documentation, le mocking pour les consommateurs et la collaboration parallèlement aux tests, une plateforme complète de cycle de vie comme Apidog est plus appropriée.
La version courte
Keploy est un outil open source qui transforme le comportement réel des API en tests. Son moteur d'enregistrement et de relecture utilise eBPF pour capturer les requêtes, les réponses et les appels de dépendance au niveau de la couche réseau sans aucune modification de code, puis les rejoue comme des tests de régression déterministes. Sa génération de tests par IA construit des suites à partir d'une spécification ou d'un point de terminaison. Il est rapide à adopter et agnostique au langage, avec les compromis d'un modèle de capture orienté Linux, des tests nécessitant une révision et un périmètre limité aux tests. Si vous souhaitez des suites de tests conçues et maintenables au sein d'une plateforme API complète, Apidog est l'alternative à laquelle le comparer.