Escolher um executor de testes CLI para o pipeline depende de duas decisões práticas: onde suas definições de API vivem hoje e o que você precisa automatizar no CI. Se sua equipe já usa Insomnia e versiona a pasta .insomnia, o inso encaixa bem. Se você quer centralizar design, mock, documentação e testes em uma plataforma com execução via CLI, o Apidog CLI muda o fluxo de trabalho.
O que cada ferramenta faz
inso é o CLI do Insomnia, cliente de API open source da Kong. Ele é usado principalmente para:
- executar coleções de requisições;
- executar suítes de testes;
- fazer lint de especificações OpenAPI com Spectral.
O inso lê os mesmos dados usados pelo app desktop do Insomnia ou por uma pasta .insomnia versionada via Git Sync.
Apidog CLI é o executor de terminal do Apidog, uma plataforma para design, depuração, mocking, documentação e testes de APIs. Ele executa cenários e coleções de um projeto Apidog, suporta testes orientados a dados e gera relatórios em diferentes formatos.
A diferença principal aparece antes da execução: o inso trabalha bem quando a fonte da verdade está no Insomnia e no Git; o Apidog CLI trabalha melhor quando a fonte da verdade está no projeto Apidog.
Apidog CLI vs inso: comparação rápida
| Capacidade | inso (Insomnia CLI) | Apidog CLI |
|---|---|---|
| Instalação |
brew install inso, Docker (kong/inso) ou download direto |
Instalador do Apidog CLI |
| O que executa | Suítes de teste e coleções de requisições | Cenários de teste e coleções de um projeto |
| Fonte de dados | Pasta .insomnia ou banco local do app Insomnia |
Projeto sincronizado no workspace Apidog |
| Teste orientado a dados | Não há flag nativo | Sim, com -d para CSV/JSON |
| Relatórios | Console e código de saída | CLI, HTML, JSON e upload com --upload-report
|
| Linting OpenAPI | Sim, com inso lint spec via Spectral |
Não há linter autônomo no CLI |
| Recursos/branches como código | Não | Sim, para endpoints, esquemas, branches e mais |
| Integração com plataforma | Cliente Insomnia | Design, mock, docs e testes no mesmo workspace |
| Código aberto | Sim | Plataforma comercial |
| Preço | Grátis | Camada gratuita disponível |
Use a tabela como filtro inicial. As próximas seções mostram como isso impacta a implementação no CI.
1. Instalação
Instalando o inso
O inso tem caminhos de instalação simples:
# Homebrew
brew install inso
# Docker
docker pull kong/inso:latest
A imagem Docker é útil em pipelines onde você não quer instalar dependências diretamente no runner.
Instalando o Apidog CLI
O Apidog CLI é instalado pela página de download do Apidog. Depois da instalação, ele executa cenários existentes no seu projeto Apidog.
Para configuração completa, consulte:
2. Defina a fonte da verdade dos testes
Essa é a decisão mais importante em uma comparação Apidog CLI vs Insomnia CLI.
Modelo do inso: pasta .insomnia
O inso referencia coleções, suítes e especificações pelo nome. Por padrão, ele busca os dados em:
- uma pasta
.insomniano diretório atual; - ou no diretório de dados do app Insomnia.
Você pode sobrescrever o caminho com --workingDir ou --src.
Exemplos:
inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging
Esse modelo funciona bem quando a equipe versiona a pasta .insomnia e mantém os nomes das suítes estáveis.
Modelo do Apidog CLI: projeto Apidog
O Apidog CLI executa cenários e coleções salvos no projeto Apidog. Você autentica o CLI, escolhe um cenário ou coleção e informa o ambiente.
Exemplo:
apidog run -t "<scenario-or-collection>" -e "<environment>"
Na prática, isso remove a necessidade de commitar uma pasta local de definições de API. O pipeline executa o que está sincronizado no workspace Apidog.
3. Execute testes orientados a dados
Se você precisa validar o mesmo fluxo com várias entradas, o suporte nativo a datasets importa.
No Apidog CLI, use -d com um arquivo CSV ou JSON:
apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv
Cada linha do arquivo vira uma iteração com variáveis próprias.
Exemplo de CSV:
orderId,userId,expectedStatus
1001,42,paid
1002,43,pending
1003,44,failed
Esse padrão é útil para cenários como:
- checkout;
- criação de usuários;
- validação de permissões;
- testes de contratos com múltiplas combinações de entrada.
Veja o guia de testes orientados a dados com o Apidog CLI.
O inso não possui uma flag nativa equivalente para iterar linha a linha em CSV/JSON. Você ainda pode automatizar esse comportamento com scripts ao redor do CLI, mas não é um recurso de primeira classe.
4. Gere relatórios úteis para o CI
No CI, o código de saída já é suficiente para aprovar ou falhar o pipeline. Mas relatórios ajudam na análise posterior.
Relatórios com Apidog CLI
O Apidog CLI suporta saída em:
- CLI;
- HTML;
- JSON;
- relatório hospedado com
--upload-report.
Exemplo:
apidog run -t "Smoke Suite" -e "CI" -r cli,html,json
Para enviar o relatório:
apidog run -t "Smoke Suite" -e "CI" -r html,json --upload-report
Use:
- CLI para leitura rápida nos logs;
- HTML como artefato do pipeline;
- JSON para dashboards ou automações downstream.
Veja o guia de relatórios de teste do Apidog CLI.
Relatórios com inso
O inso imprime os resultados no console e usa o código de saída para sinalizar sucesso ou falha. Isso cobre a necessidade básica do CI:
inso run test "Smoke Suite" --env "CI"
Se você precisa de artefatos HTML ou relatórios hospedados sem ferramentas extras, o Apidog CLI oferece mais opções.
5. Adicione linting OpenAPI quando necessário
Aqui o inso tem uma vantagem objetiva.
Ele executa lint de especificações OpenAPI com:
inso lint spec "Payments API"
O linter usado por baixo é o Spectral, bastante comum para validar padrões de especificação.
Você também pode exportar a especificação:
inso export spec "Payments API" --output openapi.yaml
Para equipes que trabalham com design spec-first e querem barrar merges com base em regras de qualidade do contrato, esse recurso é forte.
Já o Apidog CLI não possui um linter OpenAPI autônomo, nem comandos de style guide, split, merge ou bundle. O Apidog valida especificações na importação, mas isso não substitui um lint executado no CI contra regras customizadas.
Se linting OpenAPI é obrigatório, você pode:
- usar
inso lint spec; - ou adicionar uma etapa Spectral separada no pipeline;
- e usar o Apidog CLI para execução dos testes.
6. Automatize recursos e branches como código
O Apidog CLI pode gerenciar recursos da API pelo terminal, incluindo:
- importação OpenAPI;
- endpoints;
- esquemas;
- ambientes;
- branches;
- solicitações de merge.
Isso permite automatizar mudanças de design da API e conectá-las à execução dos testes.
O inso fica mais focado em execução e linting. Ele pode exportar especificações, mas não atua como CLI de gerenciamento de recursos de API.
Se sua equipe quer governar design, branches e testes com a mesma ferramenta, essa é uma diferença relevante a favor do Apidog CLI.
7. Exemplo de conexão com CI
O fluxo geral é o mesmo para as duas ferramentas:
- instalar o CLI;
- autenticar ou apontar para os dados;
- executar os testes;
- deixar o código de saída controlar a build;
- opcionalmente publicar relatórios.
Exemplo simplificado:
# inso no CI
- run: brew install inso
- run: inso run test "Smoke Suite" --env "CI"
# Apidog CLI no CI
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json
Para o Apidog CLI, estes guias detalham a configuração:
8. Plataforma, open source e preço
O inso faz parte do ecossistema Insomnia. O Insomnia é open source, e isso pode ser importante para equipes que priorizam ferramentas auditáveis ou auto-hospedáveis.
Também vale considerar o histórico recente do Insomnia: em 2023, o Insomnia 8 introduziu login obrigatório em conta de nuvem, o que gerou controvérsia e relatos de problemas de migração e perda de dados. Para contexto, veja:
- recuperação e migração de dados do Insomnia após perda;
- como recuperar e exportar dados do Insomnia.
Isso não muda o ponto principal: o inso é um executor gratuito, sólido e com linting Spectral integrado.
O Apidog é uma plataforma comercial com camada gratuita. A proposta é integrar design, mock, documentação, depuração e testes em um único workspace, com o CLI como interface de automação.
Para comparar o produto como plataforma, veja:
Para começar por execução prática:
Veredito prático
Escolha inso se:
- sua equipe já usa Insomnia;
- a pasta
.insomniaé versionada no Git; - você quer executar testes por nome no CI;
- linting OpenAPI com Spectral é obrigatório no mesmo CLI.
Escolha Apidog CLI se:
- você quer centralizar design, mock, docs e testes;
- precisa de testes orientados a dados com
-d; - quer relatórios em CLI, HTML e JSON;
- quer publicar relatórios hospedados;
- precisa gerenciar endpoints, esquemas e branches pelo CLI.
Não existe vencedor universal. O inso é mais direto para equipes já padronizadas no Insomnia e que precisam de linting OpenAPI. O Apidog CLI é mais indicado quando o objetivo é automatizar testes dentro de uma plataforma de API mais ampla.
Se você já usa inso e quer migrar, veja como migrar do inso para o Apidog CLI.
Pronto para comparar na prática? Baixe o Apidog e execute um cenário contra sua própria API.
Top comments (0)