Migrando de Keploy a Apidog CLI

Si tu equipo empezó con Keploy, probablemente valoras esto: ejecutas la app, llamas algunos endpoints y aparecen pruebas sin escribir aserciones ni stubs manuales. Keploy captura tráfico real en la capa de red y lo reproduce por ti.

Prueba Apidog hoy

El motivo habitual para migrar no es que Keploy “no sirva”, sino que necesitas otro tipo de flujo. Las pruebas capturadas son útiles para detectar regresiones sobre comportamientos que ya ocurrieron, pero pueden ser difíciles de leer, revisar y mantener en equipo. En algún momento querrás pruebas que un nuevo ingeniero pueda abrir en una PR, entender rápido y modificar con intención. También querrás datos de prueba controlados, entornos conmutables por bandera y servidores mock diseñados por ti, no derivados de una grabación.

Dos paradigmas diferentes, comparados honestamente

Keploy y Apidog coinciden en la categoría general de “pruebas de API”, pero resuelven problemas distintos.

Keploy es una plataforma open source para crear entornos de prueba aislados. Su punto fuerte es grabar y reproducir: usa eBPF en la capa de red para capturar llamadas API reales y sus dependencias, como consultas a bases de datos, servicios downstream o eventos de streaming, sin SDK y sin cambios en el código. Con ese tráfico, genera casos de prueba y mocks. También puede generar pruebas con IA desde una especificación OpenAPI, una colección de Postman, un comando cURL o un endpoint en vivo. Como la captura ocurre en la capa eBPF, es independiente del lenguaje, pero depende de Linux y privilegios elevados. Su código está en GitHub.

Apidog es una plataforma API todo en uno para diseño, depuración, mocking, documentación y pruebas. Su CLI, apidog run, ejecuta escenarios y colecciones desde la terminal o CI/CD. Soporta pruebas basadas en datos, cambio de entornos, varios formatos de reporte e informes en la nube. Apidog también genera casos de prueba con IA, pero lo hace desde tu esquema de API y tus endpoints dentro de la aplicación, no grabando tráfico de producción.

La diferencia clave: Apidog no captura tráfico en vivo vía eBPF ni genera pruebas grabando llamadas de producción junto con mocks de dependencias. Esa es la fortaleza distintiva de Keploy. Si la captura en runtime es el centro de tu flujo, conserva Keploy para eso. Lo que ganas con Apidog son pruebas diseñadas, revisables y mantenibles por equipos, más una plataforma para todo el ciclo de vida de la API.

Enfoque Keploy	Enfoque Apidog
keploy record captura tráfico real vía eBPF	Importas tu superficie API como OpenAPI, Postman o cURL
Pruebas autogeneradas desde llamadas capturadas	Generación de casos con IA desde la especificación, más escenarios creados por ti
keploy test --delay 10 reproduce grabaciones	apidog run ejecuta escenarios en CI
Mocks de dependencias capturados desde tráfico real de DB/red	Servidores mock que diseñas y controlas
Datos de prueba incluidos en la grabación	Pruebas basadas en datos con -d usando CSV/JSON
Entorno implícito de la ejecución grabada	Entornos explícitos seleccionados con -e
Linux/eBPF y privilegios elevados	Se ejecuta donde corra la CLI, incluidos runners estándar de CI

Usa esta tabla como guía de traducción, no como ranking. Cada capacidad automática de Keploy se convierte en un paso explícito de autoría en Apidog. Cambias “la herramienta lo descubrió desde el tráfico” por “el equipo definió cómo debe comportarse la API”.

Paso 1: Captura la superficie de tu API como especificación

Keploy empieza con una aplicación en ejecución. Apidog empieza con una descripción de tu API. Por eso, el primer paso es obtener una especificación importable.

Opciones habituales:

• Exporta OpenAPI desde tu framework.
• Exporta una colección de Postman si tu equipo ya la mantiene.
• Reúne comandos cURL representativos para cada endpoint.

Si ya tienes grabaciones de Keploy, úsalas como inventario. Las solicitudes capturadas muestran qué endpoints se invocan y con qué payloads. No importarás esas grabaciones directamente, pero sí pueden servir como checklist para validar que tu especificación cubre la misma superficie.

Paso 2: Importa la API en 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 endpoints, esquemas de request, parámetros y modelos de response.

Desde ese punto tienes una definición estructurada, editable y compartible de tu API. Los endpoints importados no son solo fixtures de prueba: también funcionan como documentación viva, solicitudes depurables y base para servidores mock. Para configurar la cadena completa, consulta la guía completa de la CLI de Apidog.

Paso 3: Genera una suite inicial y luego crea los escenarios reales

Aquí recuperas parte de la velocidad que te gustaba de Keploy. La generación de casos de prueba por IA de Apidog lee el esquema y los endpoints importados para crear borradores de pruebas: requests válidas, valores límite y respuestas comunes de error basadas en la especificación.

Dos puntos importantes:

1. Los casos generados por IA necesitan revisión humana. Elimina lo irrelevante y ajusta aserciones.
2. La generación parte de la especificación, no del comportamiento real en runtime. No detectará peculiaridades que solo aparecen con datos reales de producción.

Después, crea los escenarios que importan. Un escenario puede encadenar pasos como:

1. Crear usuario.
2. Iniciar sesión.
3. Extraer el token de la respuesta.
4. Consultar el perfil.
5. Actualizar datos.
6. Eliminar el usuario.

En cada paso, define aserciones sobre códigos de estado, campos de respuesta y transferencia de datos entre requests. Este trabajo era implícito dentro de una grabación de Keploy; en Apidog lo haces explícito para que sea legible, revisable y modificable. Si quieres combinar generación y autoría manual, revisa la guía sobre cómo escribir casos de prueba con asistencia de IA. También puedes comparar enfoques en el resumen de mejores generadores de casos de prueba de IA.

Paso 4: Configura entornos y datos de prueba

Una grabación contiene los valores de una ejecución concreta. Una suite diseñada debe poder ejecutarse contra distintos entornos y conjuntos de datos.

Define entornos en Apidog, por ejemplo:

• local
• staging
• production

Cada entorno puede tener su propia URL base, tokens y variables. En runtime, seleccionas el entorno con -e.

Para datos de prueba, adjunta un CSV o JSON y ejecuta el escenario una vez por fila usando -d. Así, un único flujo de login puede validar múltiples combinaciones de credenciales.

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

Esto convierte los datos de prueba en archivos que puedes versionar, revisar en PRs y ampliar cuando aparezcan nuevos casos límite. La guía de pruebas basadas en datos explica formatos y vinculación de variables.

Paso 5: Ejecuta en CI con apidog run

El comando que reemplaza a keploy test en tu pipeline es apidog run. Ejecuta escenarios creados, aplica el entorno elegido, carga datos de prueba y genera reportes.

Ejemplo:

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

En CI, el patrón es simple:

1. Instala la CLI.
2. Inyecta APIDOG_ACCESS_TOKEN como secreto.
3. Pasa el ID del escenario o colección.
4. Selecciona entorno con -e.
5. Genera reportes con -r.
6. Haz fallar el pipeline si el comando devuelve una salida no nula.

La guía de pipeline CI/CD, el tutorial de GitHub Actions y la guía de informes de prueba cubren la configuración con más detalle.

Paso 6: Construye servidores mock que controlas

Keploy genera mocks al capturar tráfico de dependencias durante la grabación. Apidog toma otro enfoque: tú diseñas el mock.

Como ya importaste tu esquema, Apidog puede generar un servidor mock a partir de él, devolviendo respuestas de ejemplo basadas en tipos de campo y reglas configuradas. Tú controlas:

• Payloads.
• Códigos de estado.
• Latencia.
• Casos de error.
• Variantes de respuesta.

La compensación es clara: los mocks capturados reflejan lo que hicieron tus dependencias; los mocks diseñados reflejan lo que tu contrato dice que deberían hacer. Para pruebas de contrato y CI estable, los mocks diseñados suelen ser más predecibles. Para más contexto, consulta las herramientas de mocking y pruebas de contrato y la generación de datos mock desde esquemas OpenAPI.

Lo que conservas y lo que cedes

Sé explícito con tu equipo sobre el cambio.

Cedes:

• Captura automática con keploy record.
• Mocks derivados de tráfico real.
• Pruebas generadas desde ejecuciones de producción.
• Magia eBPF sin cambios de código.

Ganas:

• Pruebas legibles como documentación.
• Escenarios revisables en PRs.
• Entornos seleccionables con una bandera.
• Datos de prueba versionados.
• Servidores mock controlados.
• Una plataforma para diseño, depuración, documentación y pruebas.

Si la captura del comportamiento real en runtime es crítica, mantén Keploy. Las herramientas pueden coexistir. Si necesitas pruebas mantenibles por todo el equipo, Apidog encaja mejor en ese flujo. La encuesta de herramientas de automatización de pruebas de API pone estas compensaciones en contexto, y cómo probar una API con Apidog es un buen siguiente paso práctico.

Si estás comparando ambas herramientas, la comparación entre Apidog y Keploy desglosa características una por una. Si Keploy no se ajusta a tu equipo, revisa también las mejores alternativas a Keploy.

Preguntas frecuentes

¿Puede Apidog importar mis grabaciones existentes de Keploy?

No directamente. Las grabaciones de Keploy son capturas en runtime. Apidog trabaja desde especificaciones de API. El camino práctico es exportar OpenAPI, Postman o cURL e importarlo. Usa las grabaciones de Keploy como checklist de endpoints y payloads.

¿Apidog registra tráfico en vivo y simula automáticamente mi base de datos como Keploy?

No. Apidog no captura tráfico vía eBPF y no genera mocks de dependencias desde ejecuciones reales. Esa es una fortaleza específica de Keploy. Apidog genera pruebas y mocks desde tu esquema, y tú construyes escenarios encima.

¿Qué reemplaza a keploy record y keploy test?

No hay equivalente directo a keploy record. En Apidog, el flujo es:

1. Importar una especificación.
2. Generar una suite inicial con IA.
3. Crear escenarios.
4. Ejecutarlos con apidog run.

apidog run reemplaza el rol de keploy test en CI, pero no replica la captura.

¿Vale la pena el esfuerzo adicional de autoría?

Sí, si quieres pruebas legibles, revisables y mantenidas por todo el equipo. No, si tu necesidad principal es capturar comportamiento real sin esfuerzo, incluyendo mocks de dependencias. En ese caso, conserva Keploy para ese trabajo.

¿Puedo usar Keploy y Apidog al mismo tiempo?

Sí. Un flujo razonable es usar Keploy para regresiones basadas en captura y Apidog para suites E2E diseñadas, documentación, mocks y CI estable.

Por dónde empezar

Empieza con un solo servicio:

1. Exporta su especificación OpenAPI.
2. Impórtala en Apidog.
3. Genera algunos casos con IA.
4. Crea un escenario real.
5. Añade un entorno staging.
6. Prepara un archivo CSV o JSON pequeño.
7. Ejecuta con apidog run.
8. Conéctalo a CI.

Cuando ese ciclo funcione, expande endpoint por endpoint. Cambiarás la comodidad de la grabación por pruebas que tu equipo pueda leer, cambiar y confiar. Para profundizar en la CLI, empieza con la guía de instalación y el tutorial de pruebas de API REST desde la línea de comandos.