Apidog CLI vs inso (Insomnia CLI): Qual Ferramenta de Teste de API usar no CI?

Escolher um executor de testes CLI para o seu pipeline se resume a uma pergunta simples: o que já executa suas APIs em desenvolvimento e o que você precisa automatizar no CI? Se sua equipe usa o Insomnia, o inso é o companheiro óbvio. Se você quer uma plataforma que projete, simule, documente e teste, o Apidog CLI muda a equação.

O que cada ferramenta é

inso é o companheiro de linha de comando para Insomnia, o cliente de API de código aberto da Kong. Ele traz três coisas para o terminal e CI: execução de coleções de requisições, execução de suítes de testes unitários e linting de especificações OpenAPI. Ele lê os mesmos dados que seu aplicativo Insomnia desktop usa, então se você construir requisições na GUI, o inso as executa sem interface.

Apidog CLI é o executor de terminal para Apidog, uma plataforma de API completa que cobre design, depuração, mocking, documentação e testes em um único espaço de trabalho. O CLI executa cenários de teste e coleções de um projeto, suporta execuções orientadas a dados e emite relatórios em vários formatos. Ele também pode importar OpenAPI e gerenciar recursos de API como endpoints, esquemas e branches como código.

A diferença central aparece antes de você executar um único teste. inso é um executor focado e um linter para o ecossistema Insomnia. Apidog CLI é a superfície de teste de uma plataforma mais ampla.

Apidog CLI vs inso: a tabela de comparação

A tabela é a versão resumida. As seções abaixo explicam as diferenças que realmente importam ao conectar qualquer um deles ao CI.

Instalação: brew e Docker vs o instalador Apidog

inso é distribuído através de vários canais documentados. Os mais comuns:

# Homebrew
brew install inso

# Docker
docker pull kong/inso:latest

Existem também downloads diretos para Windows, Linux e macOS. Historicamente, o inso estava no npm como insomnia-inso, mas Homebrew, Docker e os downloads diretos são os caminhos que a Kong documenta hoje. A imagem Docker é útil para executores de CI onde você não quer gerenciar uma toolchain Node.

Apidog CLI é instalado a partir da página de download do Apidog e executa cenários que vivem no seu projeto Apidog. Como os testes estão vinculados ao projeto, o CLI puxa a definição atual em vez de ler uma pasta local que você teria que manter sincronizada manualmente. Se você quiser um passo a passo completo, o guia de instalação do Apidog CLI e o guia completo do CLI cobrem a configuração de ponta a ponta.

O que cada um executa e de onde lê

Esta é a maior divisão prática na decisão apidog cli vs insomnia cli.

inso referencia suítes e especificações por nome. Você o aponta para um documento de design ou coleção pelo seu nome de exibição, e ele encontra a definição em um diretório .insomnia em seu diretório de trabalho (criado pelo Git Sync do Insomnia) ou no diretório de dados do aplicativo Insomnia se o aplicativo estiver instalado. Você sobrescreve o local com --workingDir ou --src.

inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging

O modelo baseado em nomes é limpo se sua equipe commita a pasta .insomnia e a trata como a fonte da verdade. Isso significa que seu checkout de CI precisa dessa pasta presente, e os nomes devem permanecer estáveis.

Apidog CLI executa cenários de teste que vivem no projeto Apidog. Você se autentica com um login ou token de acesso, então executa um cenário ou coleção contra um ambiente escolhido. A definição vem do projeto, então o mesmo cenário que sua equipe construiu na GUI é o que roda no CI, sem pasta para commitar e manter alinhada.

apidog run -t <scenario-or-collection> -e <environment>

Nenhum dos modelos está errado. inso favorece uma pasta local commitada no Git. Apidog favorece um projeto de registro sincronizado. Escolha aquele que corresponde à forma como sua equipe já compartilha definições de API.

Teste orientado a dados

Se você precisa executar o mesmo cenário em várias linhas de entrada, isso importa.

Apidog CLI suporta testes orientados a dados diretamente com -d, apontando para um conjunto de dados CSV ou JSON. Cada linha se torna uma iteração com suas próprias variáveis, então um cenário cobre dezenas de casos.

apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv

O padrão completo, incluindo como as variáveis se mapeiam para as colunas, está em testes orientados a dados com o Apidog CLI.

inso não expõe um flag orientado a dados em seus comandos de execução. Você pode parametrizar através de ambientes, e pode conduzir iterações roteirizando em torno do inso em seu trabalho de CI, mas a iteração linha por linha de CSV/JSON não é uma característica de primeira classe do CLI como é no Apidog. Se a iteração sobre um conjunto de dados é central para sua suíte, essa é uma diferença real a ser considerada.

Relatórios: o que você obtém de volta

Os relatórios são como o CI informa o que aconteceu. Ambas as ferramentas falham a build em caso de falha de asserção, mas diferem nos formatos de saída.

Apidog CLI produz relatórios em CLI, HTML e JSON. O formato CLI é bom para uma rápida varredura de logs, HTML oferece um artefato compartilhável e JSON alimenta dashboards ou ferramentas downstream. Você também pode enviar os resultados para a nuvem com --upload-report para um relatório hospedado e linkável. O guia de relatórios de teste do Apidog CLI detalha cada formato.

inso imprime os resultados do teste no console e sinaliza aprovação/reprovação através do código de saída, que é o que a maioria dos sistemas de CI usa. Isso cobre a necessidade principal. Se você quer um artefato HTML rico ou um relatório hospedado sem ferramentas extras, o Apidog oferece mais aqui.

Linting: a comparação honesta

É aqui que o inso tem uma vantagem genuína, e seria um desserviço fingir o contrário.

inso faz o linting de especificações OpenAPI com inso lint spec, e o linter subjacente é Spectral, o conhecido linter OpenAPI da Stoplight. Isso significa que você pode aplicar um guia de estilo, detectar problemas de contrato e barrar merges com base na qualidade da especificação, tudo a partir do mesmo CLI que executa seus testes.

inso lint spec "Payments API"
inso export spec "Payments API" --output openapi.yaml

Para equipes que praticam o design "spec-first" e querem regras de linting aplicadas no CI, esta é uma razão forte e real para escolher o inso.

Agora, a contraparte honesta para o Apidog. O Apidog CLI não possui um linter OpenAPI autônomo, guia de estilo, comando de divisão, junção ou empacotamento. O Apidog valida as especificações quando você as importa, o que detecta problemas estruturais, mas isso é validação na importação, não um comando lint que você executa contra um guia de estilo no CI. Não espere que o CLI do Apidog substitua o Spectral. Se o linting de contrato no pipeline é um requisito rígido e você não tem uma etapa Spectral separada, o inso cobre isso e o Apidog não.

Onde o Apidog ganha seu lugar é na integração e gerenciamento de recursos, que é a próxima seção.

Recurso e branch como código

O Apidog CLI pode fazer algo que o inso não faz: gerenciar recursos de API como código. Do terminal, você pode importar OpenAPI e trabalhar com endpoints, esquemas, ambientes, branches e solicitações de merge. Isso permite que você automatize alterações de design de API e as vincule à mesma automação que executa os testes.

inso permanece em sua área como um executor e linter. Ele pode exportar uma especificação, mas não é um CLI de gerenciamento de recursos para editar endpoints ou gerenciar branches.

Para equipes que desejam que sua definição de API e suas execuções de teste sejam governadas pelo mesmo CLI, a superfície de recurso-como-código do Apidog é uma vantagem significativa. Faz parte do motivo pelo qual a escolha inso vs apidog muitas vezes se transforma em uma questão de plataforma, e não apenas de executor.

Integração com a plataforma, código aberto e preços

inso faz parte de um ecossistema de código aberto. O próprio Insomnia é de código aberto, o que agrada a equipes que desejam inspecionar ou auto-hospedar suas ferramentas. Vale uma nota honesta para o planejamento: o Insomnia 8 em 2023 introduziu uma conta de nuvem/login obrigatória que gerou controvérsia, e houve incidentes de migração e perda de dados nesse período. Se sua equipe considerar esses eventos, nossos artigos sobre recuperação e migração de dados do Insomnia após perda e como recuperar e exportar dados do Insomnia cobrem os detalhes. Nada disso muda o fato de que o inso CLI é um executor sólido e gratuito com linting Spectral integrado.

Apidog é uma plataforma comercial com uma camada gratuita. Sua proposta é a integração: você projeta, simula, documenta, depura e testa em um só lugar, e o CLI é a superfície de automação para esse espaço de trabalho. Você não precisa juntar uma ferramenta de design separada, um mock server e um executor. Para uma visão mais ampla do produto, veja Apidog vs Insomnia e Insomnia vs Apidog. Se você quiser testar o executor contra uma API em tempo real primeiro, os guias como usar o Insomnia para testar uma API e testar uma API REST da linha de comando são bons pontos de partida.

Conexão CI, brevemente

Ambas as ferramentas se encaixam em um pipeline da mesma forma: instalar, autenticar ou apontar para seus dados, executar e deixar o código de saída controlar a compilação.

# 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

Se você estiver construindo isso, o guia de pipeline CI/CD do Apidog CLI e o passo a passo do GitHub Actions cobrem autenticação, cache e upload de relatórios. Os detalhes de autenticação para o executor estão no guia de autenticação do Apidog CLI.

O veredito

Não há um único vencedor. A decisão honesta se divide pela forma como sua equipe trabalha.

Escolha inso se você já usa o Insomnia, commita uma pasta .insomnia e deseja que o linting de especificações Spectral seja imposto no CI pela mesma ferramenta que executa seus testes. O ecossistema de código aberto e o linter integrado são verdadeiros pontos fortes, e um executor gratuito e referenciado por nome se encaixa perfeitamente em equipes que priorizam o Insomnia.

Escolha o Apidog CLI se você deseja uma plataforma única para design, mock, documentos e testes, com execuções orientadas a dados via -d, relatórios mais ricos (CLI, HTML, JSON, além de relatórios hospedados) e gerenciamento de recursos e branches como código. Você abre mão de um linter CLI autônomo, mas ganha um fluxo de trabalho integrado onde o que você projeta é o que você testa. Migrar uma configuração existente é simples; consulte migrar do inso (Insomnia CLI) para o Apidog CLI.

Pronto para comparar na prática? Baixe o Apidog e execute um cenário contra sua própria API.