Se sua equipe começou com Keploy, você provavelmente adora uma coisa nele: você executou seu aplicativo, acessou alguns endpoints, e os testes apareceram. Sem escrever asserções, sem simular dependências manualmente. O Keploy captura tráfego real na camada de rede e o reproduz para você.
Então, por que alguém iria querer sair do Keploy? Geralmente, isso se resume a uma necessidade diferente. Testes capturados são ótimos para detectar regressões no que já aconteceu, mas são mais difíceis de ler, revisar e gerenciar por toda a equipe. Em algum momento, você vai querer testes que um novo engenheiro possa abrir em um pull request, entender rapidamente e alterar propositalmente. Você quer dados de teste que você controla, ambientes que você alterna com uma flag, e servidores de mock que você projeta em vez daqueles derivados de uma gravação.
Dois paradigmas diferentes, comparados honestamente
Keploy e Apidog se sobrepõem nas palavras “teste de API”, mas são categorias de ferramentas diferentes. Fingir o contrário seria um desserviço para você.
Keploy é uma plataforma de código aberto para criar sandboxes de teste isoladas. Seu movimento característico é gravar e reproduzir: usando eBPF na camada de rede, ele captura chamadas de API reais e suas dependências (consultas de banco de dados, serviços downstream, eventos de streaming) sem SDK e sem alterações de código. A partir desse tráfego capturado, ele gera automaticamente casos de teste e mocks para essas dependências. Ele também possui um caminho de geração de testes por IA que constrói suítes a partir de uma especificação OpenAPI, coleção Postman, comando cURL ou um endpoint ativo. Como a captura ocorre na camada eBPF, ela é agnóstica à linguagem e depende de Linux e privilégios elevados. Você pode ler o código-fonte no GitHub.
Apidog é uma plataforma de API completa: projete, depure, simule, documente e teste em um só lugar. A CLI do Apidog (apidog run) executa cenários de teste e coleções que você criou, a partir do seu terminal e em CI/CD. Ele suporta testes orientados por dados, troca de ambiente, vários formatos de relatório e relatórios na nuvem. O Apidog também possui geração de casos de teste por IA, mas funciona a partir do seu esquema de API e endpoints dentro do aplicativo, não gravando o tráfego de produção.
Aqui está a linha honesta que você precisa antes de planejar qualquer coisa: o Apidog não captura tráfego em tempo real via eBPF, e não gera testes automaticamente gravando chamadas de produção mais mocks de dependência. Essa é a força distinta do Keploy. Se a captura em tempo de execução é o cerne do seu fluxo de trabalho, mantenha o Keploy para essa tarefa. O que você ganha ao mudar para o Apidog são testes projetados, revisáveis e colaborativos, e uma plataforma que cobre todo o ciclo de vida da API.
| Abordagem Keploy | Abordagem Apidog |
|---|---|
keploy record captura tráfego real via eBPF |
Importe sua superfície de API como OpenAPI, Postman ou cURL |
| Testes gerados automaticamente a partir de chamadas capturadas | Geração de casos de teste por IA a partir da especificação, mais cenários que você cria |
keploy test --delay 10 reproduz gravações |
apidog run executa cenários criados em CI |
| Mocks de dependência capturados de tráfego real de DB/rede | Servidores de mock que você projeta e controla |
| Dados de teste incorporados na gravação | Teste orientado a dados via -d (CSV/JSON) que você mantém |
| Ambiente implícito da execução gravada | Ambientes explícitos alternados com -e |
| Linux/eBPF, privilégios elevados | Executa em qualquer lugar onde a CLI roda, incluindo runners de CI padrão |
Leia esta tabela como um guia de tradução, não como um placar de recursos. Cada capacidade do Keploy corresponde a uma etapa de autoria deliberada no Apidog. Você está trocando “a ferramenta descobriu a partir do tráfego” por “você descreveu o que é correto”.
Passo 1: Capture sua superfície de API como uma especificação
Keploy começa de um aplicativo em execução. Apidog começa de uma descrição da sua API. Portanto, a primeira tarefa é obter essa descrição.
Se você já publica um documento OpenAPI, você terminou. Aponte para ele e siga em frente. Se não, você tem algumas opções, todas elas produzem algo importável:
- Gere OpenAPI a partir do seu framework (a maioria dos frameworks modernos possui um exportador ou uma biblioteca que o emite).
- Exporte uma coleção Postman se sua equipe já mantém uma.
- Colete os comandos cURL que você usa para acessar cada endpoint.
Um bom efeito colateral: se você tiver gravações do Keploy, as requisições capturadas são um inventário real de quais endpoints são de fato chamados e com quais payloads. Use-os como uma lista de verificação para que sua especificação cubra a mesma área, mesmo que você não importe as gravações em si.
Passo 2: Importar para o Apidog
Baixe o Apidog, crie um projeto e importe seu arquivo OpenAPI, coleção Postman ou comandos cURL. O Apidog lê a especificação e preenche endpoints, esquemas de requisição, parâmetros e modelos de resposta. Agora você tem uma definição estruturada de cada endpoint, a mesma superfície que o Keploy estava acessando, mas em um formato que você pode editar, versionar e compartilhar.
Este é também o momento em que a diferença da plataforma aparece. Esses endpoints importados não são apenas fixtures de teste. Eles são documentação viva, requisições depuráveis e a base para servidores de mock, tudo a partir de uma única importação. Para um passo a passo detalhado da cadeia de ferramentas, o guia completo da CLI do Apidog cobre toda a configuração.
Passo 3: Gere uma suíte de testes inicial e, em seguida, crie os cenários reais
Aqui é onde você recupera parte da velocidade que gostava no Keploy. A geração de casos de teste por IA do Apidog lê seu esquema e endpoints importados e elabora casos de teste para você: requisições válidas, valores de limite e respostas comuns de falha com base na especificação. É um forte ponto de partida e o tira rapidamente da página em branco. Se você quiser ver como isso se compara entre as ferramentas, o resumo dos melhores geradores de casos de teste por IA o coloca em contexto.
Duas observações honestas. Primeiro, casos rascunhados por IA (no Apidog ou Keploy) precisam de revisão humana. Trate a saída como um rascunho, remova o que não se aplica e ajuste as asserções. Segundo, esta é uma geração a partir de uma especificação, não do comportamento em tempo de execução, então ela não saberá sobre uma peculiaridade que só aparece com dados de produção reais. Essa é exatamente a lacuna que a captura do Keploy preenchia, e é a lacuna que você aceita ao mudar para testes projetados.
Então você cria os cenários que importam. Um cenário encadeia requisições em um fluxo real: criar um usuário, fazer login com o token retornado, buscar o perfil, atualizá-lo, excluí-lo. Você faz asserções sobre códigos de status, campos de resposta e como os dados são transmitidos de uma etapa para a próxima. Este é o trabalho que o Keploy fazia implicitamente em uma gravação. Fazê-lo explicitamente exige mais esforço inicial, e vale a pena toda vez que alguém lê, revisa ou altera o teste mais tarde. O guia sobre como escrever casos de teste com assistência de IA ajuda você a equilibrar a geração com a autoria manual.
Passo 4: Defina ambientes e entradas orientadas a dados
Uma gravação carrega um conjunto de valores de uma única execução. Testes criados devem rodar contra qualquer ambiente com qualquer conjunto de dados.
Defina ambientes no Apidog (local, staging, produção) com suas próprias URLs base, tokens e variáveis. No tempo de execução, você escolhe um com -e. Para dados de teste, anexe um arquivo CSV ou JSON e o Apidog executa cada cenário uma vez por linha, então um cenário de login cobre uma dúzia de combinações de credenciais. Você aponta para o arquivo com -d. O guia de testes orientados a dados mostra os formatos de arquivo e a vinculação de variáveis em detalhes.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
Esta é uma melhoria concreta em relação a uma gravação fixa. Seus dados de teste são um arquivo que você possui, revisa em pull requests e estende à medida que novos casos de contorno aparecem.
Passo 5: Execute em CI com apidog run
O comando que substitui keploy test em seu pipeline é apidog run. Ele executa seus cenários criados, aplica o ambiente e o arquivo de dados escolhidos e emite relatórios. Você pode produzir saída CLI, HTML e JSON, e enviar resultados para a nuvem com --upload-report para um link compartilhável.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
Conectar isso ao seu pipeline tem o mesmo formato de qualquer etapa de teste de CI: instale a CLI, passe seu token e ID do cenário, falhe a build em uma saída diferente de zero. O guia de pipeline CI/CD e o passo a passo de GitHub Actions cobrem o YAML exato, e o guia de relatórios de teste explica como ler a saída que sua equipe realmente irá analisar.
Passo 6: Crie servidores de mock que você controla
O Keploy oferece mocks gratuitamente, capturando o tráfego de dependência durante a gravação. O Apidog segue outro caminho: você projeta o mock. Como você já importou seu esquema, o Apidog pode gerar um servidor de mock a partir dele, retornando respostas de exemplo realistas baseadas em tipos de campo e regras que você define. Você decide a latência, os casos de erro e os payloads exatos.
A troca é a mesma que em todo o resto deste guia. Mocks capturados refletem o que suas dependências realmente fizeram; mocks projetados refletem o que você decidiu que eles deveriam fazer. Para testes de contrato e CI estável, mocks projetados tendem a vencer porque não se desviam com a produção. Se você quiser um contexto mais aprofundado, consulte ferramentas de teste de contrato e mocking e geração de dados mock a partir de esquemas OpenAPI.
O que você mantém e o que você abre mão
Seja honesto com sua equipe sobre ambos os lados desta mudança.
Você abre mão da captura automática. Sem keploy record observando o tráfego real, sem mocks de dependência derivados de execuções de produção, sem a mágica do eBPF que não precisa de código. Se essa capacidade é crucial para você, mantenha o Keploy em sua caixa de ferramentas para isso. As duas ferramentas podem coexistir.
Você ganha testes que parecem documentação, ambientes que você alterna com uma flag, dados de teste que você possui e revisa, servidores de mock que você projeta, e uma única plataforma para design, depuração, documentação e testes. O custo é real (a autoria exige mais esforço do que a gravação), e o retorno é a manutenibilidade em que toda a sua equipe pode atuar. A pesquisa mais ampla de ferramentas de automação de testes de API coloca essas compensações em contexto, e como testar uma API com Apidog é uma boa leitura prática a seguir.
Se você está comparando as duas ferramentas lado a lado, a comparação Apidog vs Keploy detalha recurso por recurso, e se o Keploy especificamente não está se adequando à sua equipe, o resumo das melhores alternativas ao Keploy vale a pena conferir.
FAQ
O Apidog pode importar minhas gravações existentes do Keploy? Não diretamente. As gravações do Keploy são capturas em tempo de execução, e o Apidog trabalha com especificações de API. O caminho prático é capturar sua superfície de API como OpenAPI (ou Postman/cURL) e importá-la. Use suas gravações do Keploy como uma lista de verificação de quais endpoints cobrir.
O Apidog grava tráfego em tempo real e simula meu banco de dados automaticamente como o Keploy? Não. O Apidog não captura tráfego via eBPF e não gera mocks de dependência automaticamente a partir de execuções reais. Essa é a força distinta do Keploy. O Apidog gera testes e mocks a partir do seu esquema, e você cria cenários com base nisso.
O que substitui keploy record e keploy test? Não há equivalente a record. Em vez disso, você importa uma especificação, gera uma suíte inicial com IA, cria cenários e os executa com apidog run no lugar de keploy test.
Vale a pena o esforço extra de autoria para migrar do Keploy? Se você deseja testes que sejam legíveis, revisáveis em pull requests e gerenciados por toda a equipe, sim. Se sua necessidade principal é a captura sem esforço do comportamento real em tempo de execução, incluindo mocks de dependência, o Keploy ainda faz isso melhor, então mantenha-o para essa tarefa.
Posso usar as duas ferramentas ao mesmo tempo? Sim. Muitas equipes usam o Keploy para verificações de regressão baseadas em captura e o Apidog para suítes end-to-end projetadas, documentação e mocks. Eles resolvem problemas diferentes.
Por onde começar
Escolha um serviço. Exporte sua especificação OpenAPI, importe-a para o Apidog, deixe a IA rascunhar alguns casos de teste e, em seguida, crie um cenário real com um ambiente e um pequeno arquivo de dados. Execute-o com apidog run e integre-o ao CI. Assim que esse ciclo parecer bom, expanda. Você trocará a conveniência da gravação por testes que toda a sua equipe pode ler, alterar e confiar. Para aprofundar na própria CLI, comece com o guia de instalação e o passo a passo de testes de API REST por linha de comando.