Cline é um loop: ele planeja uma mudança, edita arquivos, executa comandos, lê a saída e decide o que fazer em seguida. Então, por que seus testes de API não estão nesse loop? Eles ficam no Apidog, por trás de uma GUI, esperando que alguém se lembre de clicar. Seu agente nunca os toca.
A solução é um único bloco de configuração. O CLI do Apidog é um pacote npm, apidog-cli, que executa os cenários de teste que você construiu no Apidog diretamente de um terminal. Uma vez que o CLI esteja instalado e o Cline saiba que ele existe, seu agente executa um cenário do Apidog da mesma forma que executa seus testes unitários: dispara o comando, lê o código de saída, corrige o código se ele retornar vermelho.
Se você ainda não instalou o CLI, faça isso primeiro. Como instalar o CLI do Apidog com um agente de codificação de IA detalha a instalação via npm, autenticação e a primeira execução, com Cline realizando a digitação. Este artigo assume que apidog --version imprime um número e que sua conta Apidog está autenticada.
Qual Cline estamos falando
Cline é o agente de codificação autônomo de código aberto que funciona como uma extensão do VS Code (há também uma compilação para JetBrains e um CLI). Ele lê seu repositório, planeja no modo Plano, depois muda para o modo Ação para editar arquivos e executar comandos shell, solicitando aprovação com base em suas configurações de aprovação automática. Não é um chatbot hospedado; o modelo é executado em sua base de código em sua máquina. Se você tem o painel do Cline aberto no VS Code e ele está mostrando diferenças e a saída do terminal enquanto trabalha, você está no lugar certo. Como usar o Cline aborda o básico de sua instalação e escolha de um modelo.
A distinção importa porque Cline tem sua própria maneira de aprender as regras do projeto, e esse mecanismo transforma um "execute meus testes" pontual em algo que Cline busca por conta própria. Esse mecanismo é o diretório .clinerules/.
Passo 1: Adicione a regra a .clinerules, não a um lembrete no chat
Cline carrega as regras do projeto de um diretório .clinerules/ na raiz do seu workspace antes de iniciar uma tarefa. Ele lê cada arquivo .md e .txt dentro dessa pasta e os combina no conjunto de instruções que ele carrega durante a sessão. Você também pode usar um único arquivo .clinerules se preferir, mas o diretório escala melhor à medida que suas regras aumentam. Isso está documentado na referência das regras do Cline.
Crie um arquivo como .clinerules/apidog.md na raiz do seu repositório com um pequeno bloco como este:
# Teste de API com Apidog
- Para testar a API, execute o CLI do Apidog, não curl ou scripts ad-hoc.
- Comando: apidog run -t <scenario_id> -e <env_id> -r cli
- O ID do cenário e o ID do ambiente vêm da aba CI/CD do Apidog. Use esses valores exatos.
- Código de saída 0 significa que todas as asserções passaram. Não-zero significa uma falha; o código de saída é a fonte da verdade, não o seu resumo.
- A máquina já está autenticada via `apidog login`. Nunca adicione --access-token e nunca coloque um token neste arquivo.
- Se uma flag for desconhecida, execute `apidog run --help` e use a flag exata de lá.
É por isso que você escreve o CLI em .clinerules/ em vez de mencioná-lo no chat. Um ID de cenário digitado em uma mensagem do Cline desaparece quando a tarefa termina. Um em .clinerules/apidog.md está lá para cada colega de equipe que faz um checkout do repositório e para cada tarefa do Cline a partir de agora. O arquivo é versionado, então a regra viaja com o código.
Passo 2: Obtenha o comando do Apidog
Você precisa do comando apidog run real, não um adivinhado. Abra o cenário de teste no Apidog, vá para a aba CI/CD e copie o comando gerado. Ele se parece com isto:
apidog run -t 8291 -e 42 -r cli
O valor de -t é o ID do seu cenário de teste e -e é o ID do ambiente. Estes são os valores exatos que pertencem a .clinerules/apidog.md. Cole-os no bloco de regras para que Cline sempre tenha os IDs corretos. Para o conjunto completo de flags, veja a referência do comando apidog run.
Passo 3: Peça ao Cline para executar o teste
Com a regra em vigor, inicie uma tarefa no painel do Cline. Cline carrega .clinerules/ ao iniciar, então ele já sabe que o CLI está lá. Faça uma mudança que afete sua API, ou apenas peça para ele executar a verificação:
Execute o cenário de teste do Apidog e me diga o resultado.
Cline planeja o passo, então muda para o modo Ação para emitir o comando apidog run de suas regras. O quanto ele pergunta primeiro depende das suas configurações de aprovação. Cline avalia cada comando e o marca como seguro ou como necessitando de aprovação; um cenário de teste somente leitura contra um ambiente de *staging* é o tipo de comando que ele trata como seguro. Se suas configurações de aprovação automática permitem que comandos seguros sejam executados, apidog run é executado sem um prompt. Caso contrário, Cline pausa e pergunta; aprove, e ative a aprovação automática para `execute-safe-commands` se você quiser que ele execute cenários futuros por conta própria. O *reporter* -r cli imprime um resultado passo a passo e um resumo diretamente no terminal, onde você observa cada requisição e asserção à medida que acontecem.
Passo 4: Leia o relatório dentro do Cline
Quando uma execução fica vermelha, o relatório tem a resposta. Com -r cli, Cline obtém um detalhamento legível no painel de saída do terminal: cada requisição, cada asserção e qual falhou, com o valor esperado versus o valor real. A asserção falha nomeia o campo exato ou o código de status, o que geralmente é suficiente para o Cline encontrar a correção em sua próxima passagem.
Para um relatório que você pode abrir em um navegador ou entregar a um colega de equipe, adicione o *reporter* HTML:
apidog run -t 8291 -e 42 -r cli,html
O *reporter* html escreve um arquivo autocontido em ./apidog-reports. Mantenha cli na lista para que Cline ainda receba a saída inline que ele lê para decidir seu próximo passo. Para cada *flag* e *reporter*, incluindo o formato JUnit que os painéis de CI analisam, veja o guia completo do CLI do Apidog e o guia de relatórios de teste do CLI do Apidog.
Cline testando dentro do seu próprio loop
A recompensa é o que acontece quando você para de perguntar e Cline executa o cenário por conta própria porque .clinerules/ o instruiu a fazê-lo.
Imagine Cline editando um *handler* que constrói uma resposta de *checkout*. Seu loop muda: ele edita o código, então, em vez de declarar vitória, executa seu cenário Apidog contra o ambiente de *staging*, lê o código de saída e age sobre ele. Verde, ele segue em frente. Vermelho, ele abre o relatório, lê qual asserção falhou (o código de status, o campo ausente, o valor incorreto), tenta uma correção e reexecuta. O teste de API se torna parte do mesmo loop de edição-teste-correção pelo qual Cline já executa seus testes unitários. Você escreveu uma instrução e Cline integrou o comando à forma como ele já funciona.
Este é o modelo de delegar-e-verificar que torna qualquer fluxo de trabalho de agente seguro. Cline executa o comando e lê o resultado; você continua criando cenários visualmente no Apidog e verifica se o agente lê os códigos de saída honestamente. Para o padrão mais amplo, veja como usar agentes de IA para testes de API e o *harness* de teste de IA do Apidog.
Verifique se o Cline está realmente executando o CLI
Agentes relatam sucesso que não conquistaram, e Cline não é exceção. Três verificações, na ordem de quão frequentemente elas detectam problemas.
Primeiro, confirme se o comando foi executado. Cline mostra os comandos que executou e sua saída inline na visualização da tarefa. Procure a linha literal apidog run ... e um resultado abaixo dela. Se Cline diz que executou os testes, mas você não vê o comando, ele resumiu algo que nunca fez. Peça para ele executar novamente e mostrar a saída bruta.
Segundo, confirme o código de saída, o que realmente importa:
Qual foi o código de saída desse comando apidog run?
apidog run sai com 0 quando todas as asserções passam e com um valor não-zero quando algo falha. Esse comportamento único permite que Cline, ou um *pipeline*, trate a execução como um portão limpo. Quando o texto do Cline diz “testes passaram” mas o código de saída é não-zero, o código de saída está certo.
Terceiro, confirme se ele usou o cenário real. Se uma execução falha com “cenário não encontrado”, Cline pode ter inventado ou lembrado erroneamente um ID. Verifique novamente os valores -t e -e em relação a .clinerules/apidog.md e o comando que o Apidog gerou na aba CI/CD. Os IDs no arquivo de regras são a verdade.
Opcional: conecte o servidor MCP do Apidog
Executar apidog run a partir de .clinerules/ cobre a maior parte do que você precisa. Um caminho vai além.
Cline tem suporte de primeira classe para o Protocolo de Contexto do Modelo (Model Context Protocol). Na extensão do VS Code, clique no ícone MCP Servers no painel do Cline, abra Configurar e clique em Configurar MCP Servers para abrir cline_mcp_settings.json; adicione seu servidor sob o objeto mcpServers. Você também pode navegar no MCP Marketplace dentro do Cline para instalar servidores sem editar JSON manualmente, conforme descrito na documentação do MCP do Cline. O servidor MCP do Apidog expõe suas especificações de API via MCP, para que Cline possa ler seu esquema enquanto escreve código, e não apenas depois. O CLI executa os testes; o MCP alimenta o agente com a especificação.
Cline é uma extensão interativa, então não há um modo de teste não-interativo integrado a ele da mesma forma que um *runner headless* forneceria. Para executar apidog run em um *pipeline* sem o Cline presente, Apidog CLI em GitHub Actions aborda os segredos, *reporters* e controle de código de saída, e o guia do *pipeline* CI/CD do Apidog CLI aborda a configuração mais ampla.
Quando Cline erra
Algumas falhas aparecem frequentemente durante a configuração.
Ele ignora o arquivo de regras. Se Cline executa um comando genérico ou nenhum, a regra pode não estar sendo carregada. Confirme se a pasta se chama exatamente .clinerules e está na raiz do seu workspace, e que o arquivo dentro dela termina em .md ou .txt. Iniciar uma nova tarefa força Cline a recarregar as regras.
Ele passa um *access token* mesmo assim. Se Cline tenta adicionar --access-token, ele está adivinhando a partir de exemplos públicos. A regra já lhe diz para não fazer isso, já que a máquina está autenticada via apidog login. Reforce a linha e nunca coloque um token real em .clinerules/. Para entender como a autenticação realmente funciona, veja o guia de autenticação do CLI do Apidog.
Ele inventa uma *flag*. Um erro de “opção desconhecida” significa que Cline adivinhou uma *flag* que sua versão não possui. Diga a ele para executar apidog run --help e copie a *flag* exata de lá, que estará sempre correta para sua versão instalada.
Ele relata sucesso em uma execução que falhou. Este é o mais custoso, e a razão pela qual a regra do código de saída está tanto no seu arquivo .clinerules/ quanto na sua etapa de verificação. Quando o resumo e o código de saída discordam, o código de saída vence.
De um agente diário a um loop testado
Essa é a configuração. Instale apidog-cli uma vez seguindo o guia de instalação, adicione uma pequena regra do Apidog ao diretório .clinerules/ do seu repositório, e Cline saberá como executar seus testes de API e ler o resultado dentro do mesmo loop que ele já usa para editar código. Um *endpoint* quebrado é detectado enquanto Cline ainda está trabalhando na mudança, não depois que ela é implantada.
Um teste por trás de uma GUI é executado quando um humano clica; um comando de uma linha é executado sempre que Cline decide. Você continua construindo cenários visualmente no Apidog, e seu agente os executa onde você não está observando. Baixe o Apidog, construa um cenário, adicione seu comando apidog run em .clinerules/apidog.md, e veja Cline assimilá-lo na próxima mudança.