DEV Community

Cover image for Melhores Alternativas ao Hoppscotch CLI para Testes de API
Lucas
Lucas

Posted on • Originally published at apidog.com

Melhores Alternativas ao Hoppscotch CLI para Testes de API

O Hoppscotch CLI é uma forma gratuita e de código aberto de executar coleções de API a partir do terminal. Se você já usa o Hoppscotch na web ou no desktop, o hopp test permite levar essas mesmas requisições para um pipeline de CI sem custo.

Experimente o Apidog hoje

Mas o Hoppscotch CLI é propositalmente focado: ele executa coleções e retorna resultados. Ele não cobre design de API, mocking, documentação ou gerenciamento de API como código. Por isso, equipes que querem reduzir ferramentas, evitar exportações manuais de JSON ou contornar requisitos como Node.js v22 acabam avaliando alternativas.

O que o Hoppscotch CLI realmente faz

O Hoppscotch CLI é distribuído como o pacote npm @hoppscotch/cli.

Instale globalmente:

npm i -g @hoppscotch/cli
Enter fullscreen mode Exit fullscreen mode

Antes de usar, verifique a versão do Node.js. O Hoppscotch CLI atual exige Node.js v22 ou mais recente. Se seu ambiente de CI ainda usa Node 20, você fica limitado ao CLI v0.26.0, o que pode complicar imagens compartilhadas de build.

O comando principal é hopp test. Ele recebe uma coleção local ou um ID de coleção na nuvem e executa as requisições em ordem:

hopp test ./collection.json -e ./environment.json -d 500
Enter fullscreen mode Exit fullscreen mode

Para uma instância na nuvem ou auto-hospedada:

hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
Enter fullscreen mode Exit fullscreen mode

Na prática, o CLI permite:

  • executar scripts de pré-requisição;
  • executar scripts de teste com pw.test() e pw.expect();
  • validar respostas;
  • retornar código diferente de zero quando uma asserção falha;
  • gerar relatório JUnit com --reporter-junit <path>;
  • rodar iterações com --iteration-count;
  • usar dados via CSV com --iteration-data <csv>.

Exemplo em CI:

hopp test ./collection.json \
  -e ./environment.json \
  --reporter-junit ./reports/hoppscotch.xml
Enter fullscreen mode Exit fullscreen mode

Isso já é suficiente para muitos pipelines. O limite aparece quando você precisa de mais do que executar coleções.

Por que procurar uma alternativa ao hopp test

Os motivos costumam ser práticos:

  • Você precisa de mais do que um runner. Design, mocking e documentação ficam em outras ferramentas.
  • Você precisa exportar JSON. Coleções e ambientes vêm de arquivos exportados ou IDs de nuvem.
  • Node.js v22 pode ser um bloqueio. Muitas imagens de CI ainda usam versões anteriores.
  • Não há fluxo completo de especificação como código. O CLI consome o que foi definido em outro lugar; ele não gerencia endpoints, esquemas ou branches.

Isso não torna o Hoppscotch ruim. Ele apenas resolve um problema específico. Se esse escopo ficou pequeno para sua equipe, estas são boas alternativas.

1. Apidog CLI: alternativa tudo-em-um

Apidog é uma plataforma de API que cobre design, depuração, mocking, documentação e testes. O Apidog CLI leva parte desse fluxo para o terminal e para pipelines de CI/CD.

Use apidog run para executar cenários de teste e coleções pela linha de comando. Ele suporta:

  • ambientes com -e;
  • testes orientados por dados com -d usando CSV ou JSON;
  • relatórios em CLI, HTML e JSON;
  • upload de relatórios de teste para a nuvem com --upload-report;
  • importação de OpenAPI;
  • gerenciamento de recursos de API, endpoints, esquemas, ambientes, branches e solicitações de merge como código.

O ponto principal é reduzir a separação entre design e execução. Em vez de desenhar em uma ferramenta, exportar JSON e executar em outra, você mantém recursos de API e testes no mesmo sistema.

Exemplo conceitual de execução:

apidog run <scenario-or-collection-id> -e <environment-id> -d ./data.csv
Enter fullscreen mode Exit fullscreen mode

Para uso em CI, normalmente você adiciona autenticação, ambiente e saída de relatório:

apidog run <scenario-or-collection-id> \
  -e <environment-id> \
  -d ./data.json \
  --upload-report
Enter fullscreen mode Exit fullscreen mode

Escopo importante: o Apidog valida especificações na importação, mas não oferece um comando autônomo de linting OpenAPI, nem comandos como split, join ou bundle. Se seu objetivo principal é linting puro de especificações em CI, o inso ou ferramentas como Redocly são mais adequados.

Prós:

  • Uma plataforma para design, mocking, documentação e testes.
  • Execuções orientadas por dados com CSV/JSON.
  • Relatórios em CLI, HTML, JSON e nuvem.
  • Gerenciamento de endpoints, esquemas, branches e merge requests via CLI.
  • Importação direta de OpenAPI.

Contras:

  • Não possui linter OpenAPI autônomo.
  • Pode ser mais completo do que o necessário se você só precisa executar uma coleção.

Leituras úteis:

2. Newman: o runner do Postman

Newman é o runner oficial de linha de comando do Postman. Se sua equipe já usa Postman, ele é a opção com menor custo de adoção.

Fluxo básico:

newman run collection.json -e env.json -r cli,json
Enter fullscreen mode Exit fullscreen mode

Para CI, você pode gerar relatórios adicionais, como JUnit:

newman run collection.json \
  -e env.json \
  -r cli,json,junit \
  --reporter-junit-export ./reports/newman.xml
Enter fullscreen mode Exit fullscreen mode

Newman suporta:

  • relatórios CLI, JSON, JUnit e HTML via plugin;
  • arquivos de dados para iteração;
  • códigos de saída compatíveis com CI;
  • integração direta com coleções Postman exportadas.

Prós:

  • Maduro e bem documentado.
  • Excelente compatibilidade com Postman.
  • Bom suporte a relatórios e execuções orientadas por dados.

Contras:

  • Também é apenas um runner.
  • Depende do formato de coleção do Postman.
  • Ainda exige exportação de JSON.

Comparação relacionada: Apidog CLI vs Newman.

3. inso: Insomnia CLI da Kong

inso é o CLI do Insomnia, da Kong. Diferente do Hoppscotch CLI, ele também faz lint de especificações OpenAPI usando Spectral.

Exemplos:

inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
Enter fullscreen mode Exit fullscreen mode

O inso lê dados de um diretório .insomnia, geralmente criado pelo Git Sync do Insomnia, ou do diretório de dados do aplicativo. Suites e especificações são referenciadas por nome.

Instalação via Homebrew:

brew install inso
Enter fullscreen mode Exit fullscreen mode

Ou via Docker:

docker pull kong/inso:latest
Enter fullscreen mode Exit fullscreen mode

Prós:

  • Linting real de OpenAPI via Spectral.
  • Executa testes, coleções e exporta especificações.
  • Instalação via Brew ou Docker.

Contras:

  • Referenciar recursos por nome pode ser frágil em scripts.
  • O Insomnia 8 introduziu login obrigatório em conta de nuvem em 2023, o que gerou críticas e incidentes de migração/perda de dados.

Leituras úteis:

4. Step CI: testes de API em YAML

Step CI é uma ferramenta open source para testes de API definidos em YAML declarativo. Em vez de escrever scripts JavaScript, você descreve a requisição e a resposta esperada.

Execute um workflow:

npx stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

Um workflow típico fica versionado no repositório, o que facilita revisão em pull requests.

Prós:

  • YAML declarativo e legível.
  • Suporte a REST, GraphQL e gRPC.
  • Não depende de uma GUI.
  • Configuração fica no Git.

Contras:

  • Ecossistema menor.
  • Não cobre design, mocking ou documentação.
  • Você escreve os testes manualmente.

Step CI é uma boa escolha se você quer testes nativos do Git e não precisa de uma plataforma visual.

5. Hurl: teste HTTP em texto puro

Hurl executa requisições HTTP escritas em arquivos de texto puro e faz asserções sobre as respostas. Ele é baseado em libcurl, rápido e simples de revisar em pull requests.

Exemplo:

GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
Enter fullscreen mode Exit fullscreen mode

Execute com:

hurl --test health.hurl
Enter fullscreen mode Exit fullscreen mode

Prós:

  • Leve, rápido e distribuído como binário.
  • Arquivos de texto puro que também funcionam como documentação.
  • Ótimo para smoke tests e health checks em CI.

Contras:

  • Mais baixo nível do que um framework completo.
  • Não cobre design, mocking ou documentação.
  • Menos conveniente para cenários complexos, encadeados e orientados por dados.

Hurl funciona melhor quando você quer validações HTTP rápidas e legíveis.

Tabela de comparação

Ferramenta Licença Foco principal Orientado por dados Linting de especificações Design/mocking/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

Use este critério prático:

  • Você quer uma única ferramenta do design ao teste: escolha Apidog CLI.
  • Sua equipe já usa Postman: escolha Newman.
  • Você precisa de linting OpenAPI em CI: escolha inso.
  • Você quer testes declarativos versionados no Git: escolha Step CI.
  • Você quer smoke tests HTTP rápidos e simples: escolha Hurl.
  • Seu problema principal é o requisito de Node.js v22: Newman, Step CI, Hurl e inso evitam esse bloqueio específico.

Se a motivação é sair do limite de um runner de coleções, avalie uma abordagem integrada. Veja também:

FAQ

O Hoppscotch CLI é gratuito?

Sim. @hoppscotch/cli é open source e gratuito. Ele executa coleções, scripts de teste e pode gerar relatórios JUnit.

Qual é a alternativa mais simples se eu não quero depender do Node.js v22?

Hurl é uma opção simples porque é um binário único. inso pode ser instalado via Homebrew ou Docker. Step CI roda via npx, mas não tem o mesmo requisito específico de Node.js v22 do Hoppscotch CLI atual.

Posso migrar coleções do Hoppscotch para outra ferramenta?

Sim. Muitas ferramentas aceitam coleções exportadas ou especificações OpenAPI. Para a rota integrada, veja o guia migrar Hoppscotch CLI para Apidog CLI.

O Apidog CLI faz linting OpenAPI como o inso?

Não. O Apidog valida especificações na importação, mas não possui um comando autônomo de linting OpenAPI. Se você precisa aplicar regras no estilo Spectral em CI, combine com inso ou compare com uma ferramenta focada em linting: Apidog CLI vs Redocly CLI.

Qual alternativa é melhor para CI?

Todas podem funcionar em CI porque retornam código diferente de zero em caso de falha. A escolha depende do seu fluxo:

  • execução pura de coleções: Newman;
  • smoke tests leves: Hurl;
  • design e testes em uma única fonte de verdade: Apidog CLI;
  • linting de especificações: inso;
  • testes declarativos no Git: Step CI.

O Hoppscotch CLI faz bem o trabalho de runner de coleções. Se isso é tudo o que você precisa, continue com ele. Se você quer consolidar design, mocking, documentação e testes em um fluxo único, comece pelo guia completo do Apidog CLI, depois baixe o Apidog e execute seu primeiro cenário.

Top comments (0)