Si tu equipo comenzó con Keploy, probablemente haya una cosa que te encante de él: ejecutaste tu aplicación, accediste a algunos puntos finales y aparecieron las pruebas. Sin escribir aserciones, sin stubs de dependencias a mano. Keploy captura el tráfico real en la capa de red y lo reproduce por ti.
Entonces, ¿por qué querría alguien dejar Keploy? Generalmente se debe a una necesidad diferente. Las pruebas capturadas son excelentes para detectar regresiones en lo que ya sucedió, pero son más difíciles de leer, revisar y mantener por parte de un equipo. En algún momento, querrás pruebas que un nuevo ingeniero pueda abrir en una solicitud de extracción, entender de un vistazo y modificar a propósito. Querrás datos de prueba que controles, entornos que cambies con una bandera y servidores mock que diseñes en lugar de los derivados de una grabación.
Dos paradigmas diferentes, comparados honestamente
Keploy y Apidog se superponen en las palabras "pruebas de API", pero son categorías de herramientas diferentes. Fingir lo contrario te haría un flaco favor.
Keploy es una plataforma de código abierto para crear entornos de prueba aislados (sandboxes). Su característica distintiva es grabar y reproducir: utilizando eBPF en la capa de red, captura llamadas API reales y sus dependencias (consultas de bases de datos, servicios descendentes, eventos de streaming) sin SDK y sin cambios en el código. A partir de ese tráfico capturado, auto-genera casos de prueba y mocks para esas dependencias. También tiene una ruta de generación de pruebas por IA que construye suites a partir de una especificación OpenAPI, una colección de Postman, un comando cURL o un punto final en vivo. Dado que la captura ocurre en la capa eBPF, es independiente del lenguaje y se basa en Linux y privilegios elevados. Puedes leer el código fuente en GitHub.
Apidog es una plataforma API todo en uno: diseño, depuración, mock, documentación y pruebas en un solo lugar. La CLI de Apidog (apidog run) ejecuta escenarios de prueba y colecciones que hayas creado, desde tu terminal y en CI/CD. Admite pruebas basadas en datos, cambio de entorno, múltiples formatos de informe e informes en la nube. Apidog también tiene generación de casos de prueba por IA, pero funciona a partir de tu esquema de API y puntos finales dentro de la aplicación, no grabando el tráfico de producción.
Aquí tienes la línea honesta que necesitas antes de planificar cualquier cosa: Apidog no captura tráfico en vivo a través de eBPF, y no auto-genera pruebas grabando llamadas de producción más mocks de dependencias. Esa es la fortaleza distintiva de Keploy. Si la captura en tiempo de ejecución es el núcleo de tu flujo de trabajo, mantén a Keploy para ese trabajo. Lo que ganas al pasar a Apidog son pruebas diseñadas, revisables y entre equipos, y una plataforma que cubre todo el ciclo de vida de la API.
| Enfoque Keploy | Enfoque Apidog |
|---|---|
keploy record captura tráfico real a través de eBPF |
Importa tu superficie API como OpenAPI, Postman o cURL |
| Pruebas auto-generadas a partir de llamadas capturadas | Generación de casos de prueba por IA a partir de la especificación, además de escenarios que tú creas |
keploy test --delay 10 reproduce grabaciones |
apidog run ejecuta escenarios creados en CI |
| Mocks de dependencias capturados de tráfico real de DB/red | Servidores mock que tú diseñas y controlas |
| Datos de prueba incluidos en la grabación | Pruebas basadas en datos vía -d (CSV/JSON) que tú mantienes |
| Entorno implícito de la ejecución grabada | Entornos explícitos cambiados con -e |
| Linux/eBPF, privilegios elevados | Se ejecuta donde sea que se ejecute la CLI, incluidos los ejecutores de CI estándar |
Lee esta tabla como una guía de traducción, no como una tabla de puntuaciones de características. Cada capacidad de Keploy se asigna a un paso de autoría deliberado en Apidog. Estás cambiando "la herramienta lo descubrió a partir del tráfico" por "tú describiste cómo debe ser lo correcto".
Paso 1: Captura la superficie de tu API como una especificación
Keploy comienza con una aplicación en ejecución. Apidog comienza con una descripción de tu API. Así que la primera tarea es obtener esa descripción.
Si ya publicas un documento OpenAPI, ya terminaste. Apúntalo y sigue adelante. Si no, tienes algunas opciones, todas las cuales producen algo importable:
- Genera OpenAPI desde tu framework (la mayoría de los frameworks modernos tienen un exportador o una biblioteca que lo emite).
- Exporta una colección de Postman si tu equipo ya mantiene una.
- Recopila los comandos cURL que usas para acceder a cada punto final.
Un buen efecto secundario: si tienes grabaciones de Keploy, las solicitudes capturadas son un inventario real de qué puntos finales se invocan y con qué cargas útiles. Úsalos como lista de verificación para que tu especificación cubra la misma área de superficie, aunque no importarás las grabaciones en sí.
Paso 2: Importa a Apidog
Descarga Apidog, crea un proyecto e importa tu archivo OpenAPI, colección de Postman o comandos cURL. Apidog lee la especificación y rellena los puntos finales, esquemas de solicitud, parámetros y modelos de respuesta. Ahora tienes una definición estructurada de cada punto final, la misma superficie que Keploy estaba utilizando, pero en un formato que puedes editar, versionar y compartir.
Este es también el momento en que se muestra la diferencia de plataforma. Esos puntos finales importados no son solo fixtures de prueba. Son documentación en vivo, solicitudes depurables y la base para servidores mock, todo desde una única importación. Para una guía paso a paso de la cadena de herramientas, la guía completa de la CLI de Apidog cubre la configuración completa.
Paso 3: Genera una suite de pruebas inicial, luego crea los escenarios reales
Aquí es donde recuperas parte de la velocidad que te gustaba de Keploy. La generación de casos de prueba por IA de Apidog lee tu esquema y puntos finales importados y redacta casos de prueba para ti: solicitudes válidas, valores límite y respuestas comunes de fallos basados en la especificación. Es un punto de partida sólido y te permite salir rápidamente de una página en blanco. Si quieres ver cómo se compara esto entre herramientas, el resumen de los mejores generadores de casos de prueba de IA lo pone en contexto.
Dos notas honestas. Primero, los casos redactados por IA (en Apidog o Keploy) necesitan una revisión humana. Trata el resultado como un borrador, elimina lo que no se aplica y ajusta las aserciones. Segundo, esta es una generación a partir de una especificación, no del comportamiento en tiempo de ejecución, por lo que no sabrá sobre una peculiaridad que solo aparece con datos de producción reales. Esa es exactamente la brecha que llenaba la captura de Keploy, y es la brecha que aceptas cuando pasas a pruebas diseñadas.
Luego, elaboras los escenarios que importan. Un escenario encadena solicitudes en un flujo real: crear un usuario, iniciar sesión con el token devuelto, obtener el perfil, actualizarlo, eliminarlo. Asercionas códigos de estado, campos de respuesta y cómo los datos se transmiten de un paso al siguiente. Este es el trabajo que Keploy realizó implícitamente dentro de una grabación. Hacerlo explícitamente requiere más esfuerzo inicial, y vale la pena cada vez que alguien lee, revisa o cambia la prueba más tarde. La guía sobre cómo escribir casos de prueba con asistencia de IA te ayuda a equilibrar la generación con la autoría manual.
Paso 4: Configura entornos y entradas controladas por datos
Una grabación lleva un conjunto de valores de una ejecución. Las pruebas creadas deben ejecutarse contra cualquier entorno con cualquier conjunto de datos.
Define entornos en Apidog (local, staging, producción) con sus propias URL base, tokens y variables. En tiempo de ejecución, selecciona uno con -e. Para los datos de prueba, adjunta un archivo CSV o JSON y Apidog ejecuta cada escenario una vez por fila, de modo que un escenario de inicio de sesión cubre una docena de combinaciones de credenciales. Apuntas al archivo con -d. La guía de pruebas basadas en datos muestra los formatos de archivo y la vinculación de variables en detalle.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
Esta es una mejora concreta sobre una grabación fija. Tus datos de prueba son un archivo que posees, revisas en solicitudes de extracción y amplías a medida que aparecen nuevos casos límite.
Paso 5: Ejecutar en CI con apidog run
El comando que reemplaza a keploy test en tu pipeline es apidog run. Ejecuta tus escenarios creados, aplica el entorno y el archivo de datos elegidos, y emite informes. Puedes producir salidas CLI, HTML y JSON, y enviar los resultados a la nube con --upload-report para un enlace compartible.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
Conectar esto a tu pipeline tiene la misma forma que cualquier paso de prueba de CI: instala la CLI, pasa tu token y ID de escenario, y haz que la compilación falle si hay una salida no nula. La guía de pipeline CI/CD y el tutorial de GitHub Actions cubren el YAML exacto, y la guía de informes de prueba explica cómo leer la salida que tu equipo realmente consultará.Paso 6: Construye servidores mock que controlas
Keploy te ofrece mocks de forma gratuita al capturar el tráfico de dependencias durante la grabación. Apidog toma el otro camino: tú diseñas el mock. Dado que ya importaste tu esquema, Apidog puede generar un servidor mock a partir de él, devolviendo respuestas de ejemplo realistas basadas en tipos de campo y reglas que tú establezcas. Tú decides la latencia, los casos de error y las cargas útiles exactas.
La compensación es la misma que en todas partes en esta guía. Los mocks capturados reflejan lo que realmente hicieron tus dependencias; los mocks diseñados reflejan lo que decidiste que deberían hacer. Para las pruebas de contrato y CI estable, los mocks diseñados tienden a ganar porque no se desvían con la producción. Si quieres un contexto más profundo, consulta las herramientas de mocking y pruebas de contrato y la generación de datos mock a partir de esquemas OpenAPI.
Lo que conservas y lo que cedes
Sé honesto con tu equipo sobre ambos lados de este cambio.
Renuncias a la captura automática. No hay un keploy record observando el tráfico real, ni mocks de dependencias derivados de ejecuciones de producción, ni magia de eBPF que no necesita código. Si esa capacidad es fundamental para ti, mantén Keploy en tu caja de herramientas para ello. Las dos herramientas pueden coexistir.
Ganas pruebas que se leen como documentación, entornos que cambias con una bandera, datos de prueba que posees y revisas, servidores mock que diseñas y una única plataforma para diseño, depuración, documentación y pruebas. El costo es real (la autoría requiere más esfuerzo que la grabación), y la recompensa es la mantenibilidad en la que todo tu equipo puede actuar. La encuesta más amplia de herramientas de automatización de pruebas de API pone estas compensaciones en contexto, y cómo probar una API con Apidog es una buena lectura práctica a continuación.
Si estás comparando las dos herramientas lado a lado, la comparación entre Apidog y Keploy desglosa las características una por una, y si Keploy específicamente no se ajusta a tu equipo, vale la pena echar un vistazo al resumen de las mejores alternativas a Keploy.
Preguntas Frecuentes
¿Puede Apidog importar mis grabaciones existentes de Keploy? No directamente. Las grabaciones de Keploy son capturas en tiempo de ejecución, y Apidog trabaja a partir de especificaciones de API. El camino práctico es capturar la superficie de tu API como OpenAPI (o Postman/cURL) e importarla. Utiliza tus grabaciones de Keploy como una lista de verificación de los puntos finales a cubrir.
¿Apidog registra tráfico en vivo y simula automáticamente mi base de datos como Keploy? No. Apidog no captura tráfico a través de eBPF y no genera automáticamente mocks de dependencias a partir de ejecuciones reales. Esa es la fortaleza distintiva de Keploy. Apidog genera pruebas y mocks a partir de tu esquema, y tú creas escenarios sobre eso.
¿Qué reemplaza a keploy record y keploy test? No hay un equivalente a record. En su lugar, importas una especificación, generas una suite inicial con IA, creas escenarios y los ejecutas con apidog run en lugar de keploy test.
¿Vale la pena el esfuerzo adicional de autoría para migrar de Keploy? Si quieres pruebas que sean legibles, revisables en solicitudes de extracción y propiedad de todo un equipo, sí. Si tu necesidad principal es la captura sin esfuerzo del comportamiento real en tiempo de ejecución, incluyendo mocks de dependencias, Keploy aún lo hace mejor, así que consérvalo para ese trabajo.
¿Puedo ejecutar ambas herramientas a la vez? Sí. Muchos equipos usan Keploy para comprobaciones de regresión basadas en captura y Apidog para suites de extremo a extremo diseñadas, documentación y mocks. Resuelven problemas diferentes.
Por dónde empezar
Elige un servicio. Exporta su especificación OpenAPI, impórtala en Apidog, deja que la IA elabore algunos casos de prueba y luego crea un escenario real con un entorno y un pequeño archivo de datos. Ejecútalo con apidog run y conéctalo a CI. Una vez que ese ciclo te parezca bien, expande. Cambiarás la conveniencia de la grabación por pruebas que todo tu equipo pueda leer, cambiar y confiar. Para profundizar en la propia CLI, comienza con la guía de instalación y el tutorial de pruebas de API REST desde la línea de comandos.