Cline es un ciclo: planifica un cambio, edita archivos, ejecuta comandos, lee la salida y decide qué hacer a continuación. Entonces, ¿por qué sus pruebas de API no están en ese ciclo? Se quedan en Apidog detrás de una GUI, esperando que alguien se acuerde de hacer clic. Su agente nunca los toca.
La solución es un bloque de configuración. La CLI de Apidog es un paquete npm, apidog-cli, que ejecuta los escenarios de prueba que construyó en Apidog directamente desde una terminal. Una vez que la CLI está instalada y Cline sabe que existe, su agente ejecuta un escenario de Apidog de la misma manera que ejecuta sus pruebas unitarias: dispara el comando, lee el código de salida, arregla el código si regresa en rojo.
Si aún no ha instalado la CLI, hágalo primero. Cómo instalar la CLI de Apidog con un agente de codificación de IA explica la instalación de npm, la autenticación y la primera ejecución, con Cline realizando la escritura. Este artículo asume que apidog --version imprime un número y su cuenta de Apidog está autenticada.
De qué Cline estamos hablando
Cline es el agente de codificación autónomo de código abierto que se ejecuta como una extensión de VS Code (también hay una versión para JetBrains y una CLI). Lee su repositorio, planifica en modo Plan, luego cambia al modo Act para editar archivos y ejecutar comandos de shell, pidiendo aprobación según su configuración de aprobación automática. No es un chatbot alojado; el modelo se ejecuta contra su base de código en su máquina. Si tiene el panel de Cline abierto en VS Code y muestra diferencias y salida de terminal mientras trabaja, está en el lugar correcto. Cómo usar Cline cubre los conceptos básicos de su instalación y la elección de un modelo.
La distinción importa porque Cline tiene su propia forma de aprender las reglas del proyecto, y ese mecanismo convierte un “ejecutar mis pruebas” ocasional en algo que Cline busca por sí mismo. Ese mecanismo es el directorio .clinerules/.
Paso 1: Agregue la regla a .clinerules, no un recordatorio de chat
Cline carga las reglas del proyecto desde un directorio .clinerules/ en la raíz de su espacio de trabajo antes de iniciar una tarea. Lee cada archivo .md y .txt dentro de esa carpeta y los combina en el conjunto de instrucciones que lleva a cabo durante la sesión. También puede usar un único archivo .clinerules si lo prefiere, pero el directorio escala mejor a medida que sus reglas crecen. Esto está documentado en la referencia de reglas de Cline.
Cree un archivo como .clinerules/apidog.md en la raíz de su repositorio con un bloque corto como este:
# Pruebas de API con Apidog
- Para probar la API, ejecute la CLI de Apidog, no curl ni scripts ad-hoc.
- Comando: apidog run -t <scenario_id> -e <env_id> -r cli
- El ID del escenario y el ID del entorno provienen de la pestaña CI/CD de Apidog. Use esos valores exactos.
- El código de salida 0 significa que todas las aserciones pasaron. Cualquier valor distinto de cero significa una falla; el código de salida es la fuente de la verdad, no su resumen.
- La máquina ya está autenticada a través de `apidog login`. Nunca agregue --access-token y nunca ponga un token en este archivo.
- Si una bandera es desconocida, ejecute `apidog run --help` y use la bandera exacta de allí.
Es por eso que se escribe la CLI en .clinerules/ en lugar de mencionarla en el chat. Un ID de escenario escrito en un mensaje de Cline desaparece cuando la tarea termina. Uno en .clinerules/apidog.md está ahí para cada compañero de equipo que extrae el repositorio y para cada tarea de Cline de ahora en adelante. El archivo está controlado por versiones, por lo que la regla viaja con el código.
Paso 2: Obtenga el comando de Apidog
Necesita el comando real apidog run, no uno adivinado. Abra el escenario de prueba en Apidog, vaya a su pestaña CI/CD y copie el comando generado. Se ve así:
apidog run -t 8291 -e 42 -r cli
El valor -t es el ID de su escenario de prueba y -e es el ID del entorno. Estos son los valores exactos que pertenecen a .clinerules/apidog.md. Péguelos en el bloque de reglas para que Cline siempre tenga los ID correctos. Para el conjunto completo de banderas, consulte la referencia del comando apidog run.
Paso 3: Haga que Cline ejecute la prueba
Con la regla implementada, inicie una tarea en el panel de Cline. Cline carga .clinerules/ al comenzar, por lo que ya sabe que la CLI está allí. Realice un cambio que afecte su API, o simplemente pídale que ejecute la verificación:
Ejecute el escenario de prueba de Apidog y dígame el resultado.
Cline planifica el paso, luego cambia al modo Act para emitir el comando apidog run de sus reglas. Cuánto pregunta primero depende de su configuración de aprobación. Cline evalúa cada comando y lo marca como seguro o como que necesita aprobación; un escenario de prueba de solo lectura contra staging es el tipo de comando que trata como seguro. Si su configuración de aprobación automática permite que se ejecuten comandos seguros, apidog run se ejecuta sin un aviso. Si no, Cline se detiene y pregunta; apruébelo y active la aprobación automática para ejecutar comandos seguros si desea que ejecute escenarios futuros por sí solo. El reportero -r cli imprime un resultado paso a paso y un resumen directamente en la terminal, donde puede ver cada solicitud y aserción a medida que sucede.
Paso 4: Lea el informe dentro de Cline
Cuando una ejecución falla, el informe tiene la respuesta. Con -r cli, Cline obtiene un desglose legible en el panel de salida de la terminal: cada solicitud, cada aserción y cuál falló, con el valor esperado versus el real. La aserción fallida nombra el campo o código de estado exacto, lo que suele ser suficiente para que Cline encuentre la solución en su siguiente pasada.
Para un informe que pueda abrir en un navegador o entregar a un compañero de equipo, agregue el reportero HTML:
apidog run -t 8291 -e 42 -r cli,html
El reportero html escribe un archivo autocontenido en ./apidog-reports. Mantenga cli en la lista para que Cline siga obteniendo la salida en línea que lee para decidir su siguiente paso. Para todas las banderas y reporteros, incluido el formato JUnit que analizan los paneles de CI, consulte la guía completa de la CLI de Apidog y la guía de informes de pruebas de la CLI de Apidog.
Cline probando dentro de su propio ciclo
La recompensa es lo que sucede cuando deja de preguntar y Cline ejecuta el escenario por sí solo porque .clinerules/ se lo indicó.
Imagine a Cline editando un manejador que construye una respuesta de pago. Su ciclo cambia: edita el código, luego, en lugar de declarar la victoria, ejecuta su escenario de Apidog contra staging, lee el código de salida y actúa en consecuencia. Verde, continúa. Rojo, abre el informe, lee qué aserción falló (el código de estado, el campo faltante, el valor incorrecto), intenta una solución y vuelve a ejecutar. La prueba de API se convierte en parte del mismo ciclo de edición-prueba-corrección que Cline ya utiliza para sus pruebas unitarias. Usted escribió una instrucción y Cline incorporó el comando a cómo ya funciona.
Este es el modelo de delegar y luego verificar que hace que cualquier flujo de trabajo de agente sea seguro. Cline ejecuta el comando y lee el resultado; usted sigue creando escenarios visualmente en Apidog y verifica que el agente lee los códigos de salida honestamente. Para el patrón más amplio, consulte cómo usar agentes de IA para pruebas de API y el arnés de pruebas de IA de Apidog.
Verifique que Cline realmente esté ejecutando la CLI
Los agentes reportan éxitos que no obtuvieron, y Cline no es una excepción. Tres verificaciones, en orden de la frecuencia con la que detectan problemas.
Primero, confirme que el comando se ejecutó. Cline muestra los comandos ejecutados y su salida en línea en la vista de tareas. Busque la línea literal apidog run ... y un resultado debajo. Si Cline dice que ejecutó las pruebas pero no ve el comando, resumió algo que nunca hizo. Pídale que lo ejecute de nuevo y muestre la salida en bruto.
Segundo, confirme el código de salida, el que importa:
¿Cuál fue el código de salida de ese comando apidog run?
apidog run sale con 0 cuando todas las aserciones pasan y con un valor distinto de cero cuando algo falla. Ese comportamiento único permite a Cline, o a una tubería, tratar la ejecución como una puerta limpia. Cuando la prosa de Cline dice "las pruebas pasaron" pero el código de salida no es cero, el código de salida es el correcto.
Tercero, confirme que usó el escenario real. Si una ejecución falla con "escenario no encontrado", es posible que Cline haya inventado o recordado mal un ID. Vuelva a verificar los valores -t y -e contra .clinerules/apidog.md y el comando que Apidog generó en la pestaña CI/CD. Los ID en el archivo de reglas son la verdad.
Opcional: conecte el servidor MCP de Apidog
Ejecutar apidog run desde .clinerules/ cubre la mayor parte de lo que necesita. Una ruta va más allá.
Cline tiene soporte de primera clase para el Protocolo de Contexto de Modelo (MCP). En la extensión de VS Code, haga clic en el icono de Servidores MCP en el panel de Cline, abra Configurar y haga clic en Configurar Servidores MCP para abrir cline_mcp_settings.json; agregue su servidor bajo el objeto mcpServers. También puede explorar el Marketplace de MCP dentro de Cline para instalar servidores sin editar JSON manualmente, como se describe en la documentación de Cline MCP. El servidor MCP de Apidog expone sus especificaciones de API a través de MCP, para que Cline pueda leer su esquema mientras escribe código, no solo después del hecho. La CLI ejecuta las pruebas; MCP alimenta la especificación al agente.
Cline es una extensión interactiva, por lo que no tiene un modo de prueba no interactivo incorporado como lo haría un ejecutor sin cabeza. Para ejecutar apidog run en una tubería sin Cline presente, Apidog CLI en GitHub Actions cubre los secretos, los reporteros y la verificación de códigos de salida, y la guía de tuberías CI/CD de Apidog CLI cubre la configuración más amplia.
Cuando Cline se equivoca
Algunas fallas aparecen a menudo durante la configuración.
Ignora el archivo de reglas. Si Cline ejecuta un comando genérico o ninguno en absoluto, la regla puede no estar cargándose. Confirme que la carpeta se llama exactamente .clinerules y se encuentra en la raíz de su espacio de trabajo, y que el archivo dentro termina en .md o .txt. Iniciar una nueva tarea obliga a Cline a recargar las reglas.
De todos modos, pasa un token de acceso. Si Cline intenta agregar --access-token, está adivinando a partir de ejemplos públicos. La regla ya le dice que no lo haga, ya que la máquina está autenticada a través de apidog login. Refuerce la línea y nunca ponga un token real en .clinerules/. Para saber cómo funciona realmente la autenticación, consulte la guía de autenticación de la CLI de Apidog.
Inventa una bandera. Un error de "opción desconocida" significa que Cline adivinó una bandera que su versión no tiene. Dígale que ejecute apidog run --help y copie la bandera exacta de allí, que siempre es correcta para su versión instalada.
Reporta un pase en una ejecución fallida. El más costoso, y la razón por la que la regla del código de salida está tanto en su archivo .clinerules/ como en su paso de verificación. Cuando el resumen y el código de salida no coinciden, el código de salida es el que tiene razón.
De un agente diario a un ciclo probado
Esa es la configuración. Instale apidog-cli una vez siguiendo la guía de instalación, agregue una breve regla de Apidog al directorio .clinerules/ de su repositorio, y Cline sabrá cómo ejecutar sus pruebas de API y leer el resultado dentro del mismo ciclo que ya usa para editar código. Un endpoint roto se detecta mientras Cline aún está trabajando en el cambio, no después de que se envía.
Una prueba detrás de una GUI se ejecuta cuando un humano hace clic; un comando de una línea se ejecuta cada vez que Cline lo decide. Usted sigue construyendo escenarios visualmente en Apidog, y su agente los ejecuta donde usted no está mirando. Descargue Apidog, construya un escenario, coloque su comando apidog run en .clinerules/apidog.md, y observe cómo Cline lo detecta en el siguiente cambio.