O Hoppscotch CLI é uma forma gratuita e de código aberto de executar coleções de API a partir de um terminal. Se você já usa o Hoppscotch na web ou no desktop, o hopp test permite que você envie essas mesmas requisições para um pipeline de CI sem pagar por nada. Essa é uma força real, e este artigo não vai fingir o contrário.
Mas o Hoppscotch CLI também é propositalmente restrito. Ele executa coleções e relata os resultados. Não projeta APIs, não as simula, não as documenta ou as gerencia como código. Assim, muitas equipes chegam a um ponto em que desejam uma única ferramenta que faça mais do que executar um arquivo JSON, ou encontram um ponto de atrito, como o requisito do Node v22, e começam a procurar alternativas.
O que o Hoppscotch CLI realmente faz
O Hoppscotch CLI é distribuído como o pacote npm @hoppscotch/cli. Você o instala globalmente:
npm i -g @hoppscotch/cli
Uma coisa a saber de antemão: ele precisa do Node.js v22 ou mais recente. Se você está preso ao Node 20, você permanece no CLI v0.26.0, o que pode complicar uma imagem de CI compartilhada onde outros trabalhos fixam uma versão mais antiga do Node.
O comando principal é hopp test. Você o aponta para um arquivo de coleção (ou um ID de coleção na nuvem) e ele executa cada requisição em ordem:
hopp test ./collection.json -e ./environment.json -d 500
Para instâncias na nuvem ou auto-hospedadas, você passa um ID e as credenciais:
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
Ele executa scripts de pré-requisição e scripts de teste (suites pw.test(), casos pw.expect()), valida as respostas e sai com código diferente de zero se alguma asserção falhar. Ele também suporta --reporter-junit <path> para JUnit XML, além de --iteration-count e --iteration-data <csv> para execuções orientadas por dados. É um runner gratuito genuinamente capaz.
Por que as equipes procuram uma alternativa ao hopp test
Os motivos pelos quais as pessoas procuram um substituto para o Hoppscotch CLI são geralmente práticos, não ideológicos:
- É um executor de coleções, nada mais. O design, a simulação (mocking) e a documentação ficam em outro lugar. Você acaba juntando várias ferramentas.
- Você precisa exportar JSON primeiro. Especificações e ambientes vêm como arquivos de coleção/ambiente exportados (ou IDs de nuvem). Não há linting de especificações ou camada de design no próprio CLI.
- O requisito mínimo do Node v22. Mais recente do que muitas imagens de build padrão, o que significa um malabarismo extra de versões.
- Nenhum fluxo de trabalho de especificação como código. Você não pode gerenciar endpoints, esquemas ou branches a partir do CLI. O CLI é um consumidor do que foi definido em outro lugar.
Nada disso torna o Hoppscotch ruim. Isso o torna uma ferramenta focada. Se você deseja uma cobertura mais ampla, aqui estão as alternativas que valem a pena seu tempo.
1. Apidog CLI (melhor alternativa tudo-em-um)
Apidog é uma plataforma de API tudo-em-um que cobre design, depuração, simulação (mocking), documentação e testes. O Apidog CLI traz o lado de testes e gerenciamento de recursos para o terminal e CI/CD, o que o torna uma forte alternativa a um runner de coleções autônomo.
Com apidog run você executa cenários de teste e coleções a partir da linha de comando. Ele suporta testes orientados por dados através de -d (conjuntos de dados CSV ou JSON), ambientes via -e, relatórios nos formatos CLI, HTML e JSON, e relatórios de teste na nuvem com --upload-report. Além de executar testes, o CLI pode importar OpenAPI e gerenciar recursos de API, endpoints, esquemas, ambientes, branches e solicitações de merge, como código. Assim, sua definição de API e seus testes vivem no mesmo sistema em vez de serem exportados e importados repetidamente.
Para ser preciso sobre o escopo: o Apidog valida as especificações na importação, mas não vem com um linter OpenAPI autônomo ou um comando split/join/bundle. Se o linting puro de especificações em CI é seu objetivo, o inso (abaixo) é a melhor opção. A proposta do Apidog é integração: você projeta, simula, documenta e testa em um só lugar, e então gerencia as camadas de teste e recursos a partir do CLI.
Prós:
- Uma plataforma para design, simulação, documentação e teste em vez de uma cadeia de ferramentas
- Execuções orientadas por dados com conjuntos de dados CSV/JSON
- Relatórios em CLI, HTML e JSON, além de relatórios de nuvem que podem ser enviados
- Recurso como código: gerencie endpoints, esquemas, branches e solicitações de merge a partir do CLI
- Importa OpenAPI diretamente
Contras:
- Nenhum comando de linter de especificações autônomo (use inso ou Redocly para linting no estilo Spectral)
- A plataforma completa é mais do que você precisa se você só executa uma coleção
Se você está comparando os dois, veja Apidog CLI vs Hoppscotch CLI e o prático tutorial migrar Hoppscotch CLI para Apidog CLI. O guia completo do Apidog CLI abrange instalação, autenticação e o conjunto completo de comandos. Para experimentá-lo, baixe o Apidog.
2. Newman (o runner do Postman)
Newman é o runner oficial de coleções de linha de comando do Postman. Se sua equipe já usa o Postman, Newman é o caminho de menor resistência: exporte a coleção e o ambiente, então execute-os em CI.
newman run collection.json -e env.json -r cli,json
Ele suporta múltiplos relatórios (CLI, JSON, JUnit, HTML via um plugin), arquivos de dados para iteração e um contrato de código de saída estável para pipelines.
Prós:
- Maduro, amplamente documentado, ecossistema enorme
- Compatibilidade de primeira classe com Postman
- Relatórios flexíveis e iterações orientadas por dados
Contras:
- Assim como o Hoppscotch CLI, é apenas um runner, sem camada de design ou documentos
- Vinculado ao formato de coleção do Postman e seu modelo de script
- Você ainda precisa exportar JSON para usá-lo
Para uma comparação direta com a abordagem do Apidog, veja Apidog CLI vs Newman.
3. inso (Insomnia CLI da Kong)
inso é o companheiro de linha de comando do cliente Insomnia de código aberto da Kong. Ele faz algo que o Hoppscotch CLI não faz: ele faz lint das especificações OpenAPI. O linting é executado no Spectral, o linter OpenAPI da Stoplight, então se as verificações de qualidade de especificação em CI são importantes para você, o inso é um verdadeiro concorrente.
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
o inso lê de um diretório .insomnia (criado pelo Git Sync do Insomnia) ou do diretório de dados do aplicativo, e referencia suites e especificações por nome. Você pode instalá-lo com brew install inso ou docker pull kong/inso:latest.
Prós:
- Linting real de OpenAPI via Spectral
- Execute testes e coleções, exporte especificações, tudo a partir do terminal
- Caminhos de instalação Brew e Docker
Contras:
- Referencia recursos por nome, o que pode ser frágil em scripts
- O Insomnia 8 introduziu uma conta de nuvem/login obrigatória em 2023 que gerou críticas, e houve incidentes de migração e perda de dados relacionados a essa mudança. Vale a pena saber se você está adotando o ecossistema pela primeira vez.
Se você está avaliando o Insomnia de forma mais ampla, Apidog vs Insomnia e melhores alternativas ao aplicativo Insomnia são boas leituras. Há também uma comparação focada Apidog CLI vs inso (Insomnia CLI).
4. Step CI (teste de API de código aberto em YAML)
Step CI é uma ferramenta de qualidade de API de código aberto que define testes em YAML declarativo em vez de JS roteirizado. Você descreve a requisição e a resposta esperada, e ele as verifica. Suporta REST, GraphQL e gRPC, o que é uma cobertura de protocolo mais ampla do que a maioria dos runners de coleção.
npx stepci run workflow.yml
Prós:
- YAML declarativo, fácil de ler no controle de versão
- Multi-protocolo (REST, GraphQL, gRPC)
- Nenhuma dependência de GUI, a configuração reside inteiramente no seu repositório
Contras:
- Comunidade e ecossistema menores
- Nenhuma camada de design, simulação ou documentação
- Você escreve testes manualmente em YAML em vez de gravá-los
Step CI é uma boa opção se você deseja testes nativos do Git, legíveis por humanos e não precisa de nenhuma UI.
5. Hurl (teste HTTP em texto puro)
Hurl executa requisições HTTP escritas em um formato simples de texto puro e faz asserções nas respostas. É construído sobre libcurl, executa rápido e produz uma saída limpa. Não há scripts nem coleções JSON, apenas arquivos .hurl que você pode comparar em um pull request.
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
Execute-o com:
hurl --test health.hurl
Prós:
- Extremamente leve, binário único, rápido
- Arquivos de texto puro que parecem documentação
- Ótimo para testes de fumaça e verificações de saúde em CI
Contras:
- Nível inferior a um framework de teste completo
- Nenhum recurso de design, simulação ou documentos
- Menos conveniente para cenários complexos, encadeados e orientados por dados
Hurl se destaca para verificações rápidas e legíveis de contrato e testes de fumaça. Não está tentando ser uma plataforma.
Tabela de comparação
| Ferramenta | Licença | Foco principal | Orientado por dados | Linting de especificações | Design/simulação/docs | Formatos de relatório |
|---|---|---|---|---|---|---|
| Apidog CLI | Comercial (nível gratuito) | Plataforma completa + testes CLI | Sim (CSV/JSON) | Não (valida na importação) | Sim | CLI, HTML, JSON, nuvem |
| Hoppscotch CLI | Código aberto | Executor de coleções | Sim (iterações CSV) | Não | Não | CLI, JUnit |
| Newman | Código aberto | Executor do Postman | Sim (arquivos de dados) | Não | Não | CLI, JSON, JUnit, HTML |
| inso | Código aberto | Executor do Insomnia + linter | Limitado | Sim (Spectral) | Parcial (docs de design) | CLI, JUnit |
| Step CI | Código aberto | Testes de API em YAML | Sim | Não | Não | CLI, JUnit |
| Hurl | Código aberto | Testes HTTP em texto puro | Via templating | Não | Não | CLI, JUnit, HTML |
Como escolher
- Você quer uma ferramenta única para design até testes: Apidog CLI. Ele remove a dança de exportar JSON e depois executar, e mantém seus recursos de API e testes no mesmo sistema.
- Sua equipe já usa o Postman: Newman. Menor custo de mudança.
- Você precisa de linting OpenAPI em CI: inso, por causa do Spectral.
- Você quer testes nativos do Git e declarativos: Step CI (YAML) ou Hurl (texto puro).
- Você está feliz com um runner OSS gratuito e só quer sair do Node 22: qualquer um dos acima, já que Newman, Step CI e Hurl não compartilham esse requisito.
Se sua principal razão para sair é o limite do runner de coleções, e não qualquer aborrecimento único, a rota integrada é a primeira a ser considerada. Veja Apidog CLI vs Postman CLI e pipeline CI/CD do Apidog CLI para ver como o lado de testes se encaixa em um pipeline real, e relatórios de teste do Apidog CLI para as opções de relatório.
FAQ
O Hoppscotch CLI é gratuito? Sim. @hoppscotch/cli é de código aberto e gratuito para usar. Ele executa coleções, scripts de teste e emite relatórios JUnit. As alternativas aqui não são sobre o Hoppscotch ser caro, mas sim sobre querer mais do que um runner.
Qual é a alternativa mais simples ao Hoppscotch CLI se eu não quero o Node v22? Hurl é um binário único sem nenhuma dependência de Node. inso instala via Homebrew ou Docker. Step CI executa via npx, mas não está fixado no Node 22 da mesma forma que o Hoppscotch CLI atual.
Posso mover minhas coleções existentes do Hoppscotch para outra ferramenta? Sim. A maioria das ferramentas aceita coleções exportadas ou OpenAPI. Para a rota integrada, o guia migrar Hoppscotch CLI para Apidog CLI mostra como importar e reexecutar suas suites.
O Apidog CLI faz linting de especificações OpenAPI como o inso? Não. O Apidog valida as especificações na importação, mas não possui um comando linter autônomo. Se a aplicação de guias de estilo no estilo Spectral em CI for um requisito rígido, combine o Apidog com o inso ou use Apidog CLI vs Redocly CLI para comparar a opção focada em linting.
Qual alternativa é melhor para um pipeline de CI? Todas elas retornam códigos de saída diferentes de zero em caso de falha, então todas funcionam em CI. O fator decisivo é o que mais você precisa: execuções puras favorecem Newman ou Hurl; uma única fonte de verdade para design e testes favorece Apidog CLI; verificações de especificação favorecem inso.
O Hoppscotch CLI faz seu único trabalho bem. Se esse único trabalho é tudo o que você precisa, continue com ele. Se você prefere consolidar design, simulação, documentação e testes em um único fluxo de trabalho, em vez de conectar vários runners, uma plataforma integrada é a melhor opção. Comece com o guia completo do Apidog CLI, então baixe o Apidog e execute seu primeiro cenário.