Se sua equipe começou com Keploy, provavelmente foi por um motivo simples: você executou o app, chamou alguns endpoints e os testes apareceram. Sem escrever asserções, sem mockar dependências manualmente. O Keploy captura tráfego real na camada de rede e reproduz esse comportamento depois.
A migração para o Apidog faz sentido quando a necessidade muda: em vez de testes derivados de gravações, você quer testes legíveis, revisáveis em pull requests, parametrizados por ambiente e mantidos pela equipe. Em outras palavras: sair de “o teste foi descoberto pelo tráfego” para “o comportamento esperado foi descrito explicitamente”.
Keploy vs Apidog: entenda a diferença antes de migrar
Keploy e Apidog aparecem na mesma conversa porque ambos ajudam com testes de API, mas resolvem problemas diferentes.
Keploy é uma plataforma open source focada em gravar e reproduzir comportamento real. Ele usa eBPF na camada de rede para capturar chamadas de API e dependências como banco de dados, serviços downstream e eventos de streaming, sem SDK e sem alterações no código. A partir disso, gera testes e mocks automaticamente. O código está disponível no GitHub.
Apidog é uma plataforma completa para projetar, depurar, mockar, documentar e testar APIs. A CLI do Apidog, via apidog run, executa cenários e coleções criados no projeto, tanto localmente quanto em CI/CD. Ele suporta ambientes, dados externos, relatórios e geração de casos de teste por IA a partir da especificação da API.
Ponto importante: o Apidog não substitui o recurso de captura via eBPF do Keploy. Ele não grava tráfego de produção nem gera mocks automaticamente a partir de dependências reais. Se esse fluxo é essencial, mantenha o Keploy para essa parte. A migração para o Apidog é indicada quando você quer testes mais explícitos, colaborativos e fáceis de manter.
| Abordagem Keploy | Abordagem Apidog |
|---|---|
keploy record captura tráfego real via eBPF |
Importe sua API como OpenAPI, Postman ou cURL |
| Testes são gerados a partir de chamadas capturadas | Testes são criados a partir da especificação e de cenários definidos |
keploy test --delay 10 reproduz gravações |
apidog run executa cenários no terminal ou CI |
| Mocks vêm do tráfego real de dependências | Mocks são projetados e controlados por você |
| Dados ficam embutidos na gravação | Dados externos via CSV/JSON com -d
|
| Ambiente vem da execução gravada | Ambientes explícitos com -e
|
| Requer Linux/eBPF e privilégios elevados | Roda onde a CLI estiver disponível, incluindo runners de CI |
Use essa tabela como um mapa de migração. Cada comportamento implícito do Keploy vira uma configuração explícita no Apidog.
Passo 1: transforme sua superfície de API em uma especificação
O Keploy começa com um app em execução. O Apidog começa com uma descrição da API.
Se você já tem OpenAPI, use esse arquivo como ponto de partida. Se não tem, escolha uma destas opções:
- gerar OpenAPI a partir do framework usado pela aplicação;
- exportar uma coleção Postman existente;
- reunir comandos cURL usados para chamar os principais endpoints.
Se você já possui gravações do Keploy, use-as como checklist. Elas mostram quais endpoints foram realmente chamados e com quais payloads. Você não precisa importar as gravações diretamente, mas pode usá-las para garantir que a especificação cobre a mesma superfície.
Exemplo de inventário prático:
GET /users/{id}
POST /auth/login
POST /orders
GET /orders/{id}
PATCH /orders/{id}/status
Depois, verifique se cada rota existe na especificação OpenAPI ou na coleção que será importada.
Passo 2: importe a API no Apidog
Baixe o Apidog, crie um projeto e importe seu arquivo OpenAPI, coleção Postman ou comandos cURL.
Ao importar, o Apidog cria a estrutura de endpoints, parâmetros, schemas de request e modelos de response. Essa passa a ser a base para documentação, debugging, mocks e testes.
Depois da importação, valide pelo menos estes pontos:
- se as URLs e métodos HTTP estão corretos;
- se parâmetros obrigatórios aparecem como obrigatórios;
- se os exemplos de request e response fazem sentido;
- se os códigos de status esperados estão documentados;
- se os schemas estão completos o suficiente para gerar mocks e testes.
Para uma visão completa da CLI, veja o guia completo da CLI do Apidog.
Passo 3: gere uma suíte inicial e revise manualmente
Para recuperar parte da velocidade do Keploy, use a geração de casos de teste por IA do Apidog.
Ela usa os endpoints e schemas importados para criar casos iniciais, como:
- request válida;
- campos obrigatórios ausentes;
- valores de limite;
- payload inválido;
- respostas comuns de erro.
Trate esses testes como rascunho. Revise:
- se as asserções refletem a regra de negócio real;
- se os dados de exemplo são válidos;
- se os cenários negativos fazem sentido;
- se algum endpoint crítico ficou de fora.
A diferença em relação ao Keploy é importante: a IA do Apidog trabalha a partir da especificação, não a partir do tráfego real. Se existe uma peculiaridade que só aparece em produção, você precisa adicioná-la manualmente ao cenário.
Para comparar abordagens, veja também o resumo dos melhores geradores de casos de teste por IA.
Passo 4: crie cenários end-to-end explícitos
Depois da suíte inicial, crie os fluxos que realmente validam a API.
Um cenário típico pode encadear chamadas assim:
1. Criar usuário
2. Fazer login
3. Extrair token da resposta
4. Buscar perfil autenticado
5. Atualizar perfil
6. Excluir usuário
O objetivo é transformar uma sequência real de uso em um teste legível e revisável.
Em cada etapa, defina asserções como:
Status code = 201
response.body.id existe
response.body.email = email enviado no request
token não está vazio
Esse é o trabalho que o Keploy fazia implicitamente ao gravar uma execução. No Apidog, você escreve o fluxo de forma explícita. O esforço inicial é maior, mas o resultado é mais fácil de entender, revisar e alterar.
O guia sobre como escrever casos de teste com assistência de IA ajuda a combinar geração automática com revisão manual.
Passo 5: configure ambientes
Uma gravação do Keploy carrega os valores de uma execução específica. No Apidog, o ideal é separar teste e ambiente.
Crie ambientes como:
localstagingproduction
Cada ambiente pode ter variáveis próprias:
base_url=https://api-staging.example.com
auth_token=...
tenant_id=...
Na execução, escolha o ambiente com -e:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging"
Esse padrão permite rodar o mesmo cenário contra ambientes diferentes sem duplicar testes.
Passo 6: use dados externos com CSV ou JSON
Para testes orientados a dados, mantenha entradas em arquivos versionados junto com o projeto.
Exemplo de CSV para login:
email,password,expected_status
user@example.com,correct-password,200
user@example.com,wrong-password,401
blocked@example.com,any-password,403
Execute o cenário usando -d:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
Isso substitui a limitação de uma gravação fixa. Agora os dados de teste são explícitos, revisáveis em pull request e fáceis de expandir.
O guia de testes orientados a dados mostra os formatos suportados e como vincular variáveis.
Passo 7: execute no CI com apidog run
No pipeline, o comando que substitui keploy test é apidog run.
Exemplo:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
Esse comando:
- executa o cenário ou coleção indicada;
- aplica o ambiente escolhido;
- usa dados externos, se configurados;
- gera relatório em CLI, HTML ou JSON;
- pode enviar o relatório para a nuvem com
--upload-report.
Em CI, o fluxo básico é:
1. Instalar a CLI do Apidog
2. Configurar APIDOG_ACCESS_TOKEN como secret
3. Rodar apidog run
4. Falhar a build se o comando retornar erro
5. Publicar ou armazenar o relatório
Para YAMLs prontos e exemplos de integração, consulte:
Passo 8: crie mocks controlados
O Keploy gera mocks capturando dependências durante a gravação. O Apidog usa outra abordagem: mocks projetados a partir do schema.
Como sua API já foi importada, você pode gerar um servidor de mock baseado nos modelos, exemplos e regras definidas. Isso permite controlar:
- payloads de sucesso;
- respostas de erro;
- códigos de status;
- latência;
- formatos de campos;
- cenários específicos para frontend ou testes de contrato.
A diferença prática é:
Mock capturado: reflete o que aconteceu em uma execução real.
Mock projetado: reflete o contrato que você quer garantir.
Para CI estável e desenvolvimento desacoplado, mocks projetados costumam ser mais previsíveis. Para entender melhor esse fluxo, veja:
O que você ganha e o que perde
Ao migrar do Keploy para o Apidog, seja explícito com a equipe.
Você perde:
- captura automática via
keploy record; - mocks gerados a partir de tráfego real;
- reprodução direta de execuções capturadas;
- a camada eBPF agnóstica à linguagem.
Você ganha:
- testes legíveis e revisáveis;
- cenários criados com intenção;
- ambientes alternáveis com
-e; - dados versionados com
-d; - documentação, debugging, mocks e testes na mesma plataforma;
- execução simples em CI com
apidog run.
Se captura de comportamento real é essencial, use Keploy e Apidog juntos. Por exemplo:
Keploy: regressões baseadas em tráfego capturado.
Apidog: testes end-to-end projetados, documentação, mocks e CI.
Para comparar opções, veja a pesquisa de ferramentas de automação de testes de API e o guia prático de como testar uma API com Apidog.
Se você ainda está avaliando a troca, leia também a comparação Apidog vs Keploy e o resumo das melhores alternativas ao Keploy.
Checklist de migração
Use este checklist para começar com baixo risco:
[ ] Escolher um serviço pequeno
[ ] Exportar ou criar a especificação OpenAPI
[ ] Importar a API no Apidog
[ ] Validar endpoints, schemas e exemplos
[ ] Gerar casos iniciais com IA
[ ] Revisar e remover testes irrelevantes
[ ] Criar um cenário end-to-end real
[ ] Configurar ambiente staging
[ ] Criar arquivo CSV/JSON de dados
[ ] Rodar com apidog run localmente
[ ] Adicionar execução ao CI
[ ] Publicar relatório para a equipe
[ ] Expandir para outros endpoints
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. O Apidog trabalha a partir de especificações de API, coleções Postman ou comandos cURL. Use as gravações como checklist para cobrir os mesmos endpoints.
O Apidog grava tráfego em tempo real como o Keploy?
Não. O Apidog não captura tráfego via eBPF e não gera mocks automaticamente a partir de dependências reais. Essa é uma capacidade específica do Keploy.
O que substitui keploy record?
Não há equivalente direto. No Apidog, o fluxo é importar uma especificação, gerar uma suíte inicial, criar cenários e configurar mocks controlados.
O que substitui keploy test?
O equivalente operacional no pipeline é:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging"
Ele executa os cenários criados no Apidog.
Vale a pena migrar?
Sim, se sua prioridade é ter testes legíveis, revisáveis, parametrizados e mantidos pela equipe. Se sua prioridade principal é capturar comportamento real com o mínimo de configuração, o Keploy continua sendo mais adequado para essa parte.
Posso usar Keploy e Apidog juntos?
Sim. Essa pode ser a melhor estratégia em muitos times: Keploy para regressão baseada em captura e Apidog para design, documentação, mocks, testes end-to-end e CI.
Por onde começar
Escolha um serviço pequeno. Exporte a especificação OpenAPI, importe no Apidog, gere casos iniciais com IA e crie um cenário real com ambiente e dados externos. Depois, rode com apidog run e integre ao CI.
Quando esse fluxo estiver estável, expanda para mais endpoints.
Para aprofundar na CLI, comece pelo guia de instalação e pelo passo a passo de testes de API REST por linha de comando.
Top comments (0)