Melhores Ferramentas de Teste de API na Linha de Comando em 2026

O teste de API saiu da GUI. Hoje, os testes rodam em contêineres de CI sem display, em ambientes de staging acessados por SSH e até sob agentes de IA que executam apenas comandos shell. Nesses cenários, o terminal é o ponto em que um teste passa ou falha sem supervisão humana.

Experimente o Apidog hoje

Este guia classifica ferramentas que executam testes reais a partir do shell. Aqui, “baseado em terminal” significa que o ciclo completo acontece no shell: instalação por gerenciador de pacotes, execução de um comando e leitura do código de saída. A avaliação considera asserções embutidas, fluxos de várias etapas, relatórios para CI e status de manutenção.

Clientes manuais, como curl, também aparecem na lista porque continuam sendo úteis durante a exploração e a depuração. Para uma pesquisa mais ampla, incluindo ferramentas GUI e hospedadas, consulte o resumo das melhores ferramentas gratuitas para teste de API.

O que separa uma ferramenta de teste de um cliente

Um cliente de terminal envia uma requisição e mostra a resposta. Uma ferramenta de teste também avalia a resposta e retorna um código de saída que o pipeline pode usar para aprovar ou bloquear uma build.

Os principais critérios são:

• Asserções embutidas: validação de status, cabeçalhos e corpo sem depender de scripts extensos com jq.
• Códigos de saída previsíveis: 0 para sucesso e diferente de 0 para falha.
• Repetibilidade: testes armazenados em arquivos ou projetos versionáveis.
• Relatórios: saída legível no terminal e formatos como JSON, JUnit ou HTML para CI.

Com esses critérios, estas são as dez ferramentas que merecem atenção em 2026.

1. Apidog CLI: crie visualmente e execute sem interface gráfica

O Apidog é uma plataforma que reúne design, testes, mocking e documentação de APIs. O Apidog CLI, instalado como apidog-cli pelo npm, permite criar cenários no editor visual e executá-los em qualquer shell.

Os cenários podem incluir:

• Requisições encadeadas.
• Variáveis extraídas de respostas.
• Asserções.
• Dados de teste em CSV ou JSON.
• Relatórios para CI.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copie o comando exato na aba CI/CD do cenário
apidog run -t <scenario_id> -e <env_id> -r cli

Você não precisa adivinhar os IDs. Abra o cenário no Apidog, acesse a aba CI/CD e copie o comando gerado.

Os relatores disponíveis incluem:

• cli
• html
• json
• junit

Os arquivos são gravados em apidog-reports/, permitindo alimentar o terminal, um painel de CI e um armazenamento de artefatos com a mesma execução.

A saída JSON inclui agentHints.nextSteps, útil quando um agente de codificação precisa executar uma suíte e decidir o próximo passo sem fazer parsing de uma tela. O CLI exige Node.js 16 ou posterior.

Melhor para: equipes que precisam de cenários complexos, criados visualmente e executados de forma consistente em laptops, CI e agentes automatizados.

Limitação: não é open source nem um remetente ad-hoc. Os cenários ficam em um projeto Apidog, portanto esta é uma opção de plataforma integrada, e não apenas uma ferramenta HTTP básica.

O guia completo do Apidog CLI cobre os comandos disponíveis.

2. Hurl: testes em texto puro em um único binário Rust

O Hurl executa requisições HTTP descritas em texto puro e valida as respostas. Construído em Rust sobre o libcurl, ele é distribuído como um único binário.

Isso facilita:

• Revisar testes em pull requests.
• Versionar cenários junto com o código.
• Executar testes sem instalar um runtime adicional.

brew install hurl
# Alternativa:
# cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

# Retorna código diferente de zero se uma asserção falhar
hurl --test login.hurl

Melhor para: testes de fumaça e verificações de contrato mantidos como texto legível.

Limitação: é focado em HTTP. Não executa gRPC nem gera carga, e cenários mais complexos podem exigir vários arquivos .hurl em vez de uma linguagem de script.

3. Newman: execute coleções do Postman sem GUI

O Newman é o executor de linha de comando open source para coleções do Postman, sob licença Apache-2.0.

Se a equipe já mantém requisições e testes no Postman, exporte a coleção e o ambiente em JSON e execute-os no terminal:

npm install -g newman

newman run collection.json -e staging.json

O Newman retorna um código diferente de zero quando um teste falha, o que permite bloquear a build no CI.

Melhor para: equipes que já investiram em coleções do Postman e querem executá-las em pipelines sem uma interface gráfica.

Limitação: executa apenas coleções no formato Postman. A criação dos testes continua acontecendo na GUI do Postman; o Newman apenas executa o que já foi criado.

4. Postman CLI: a alternativa oficial ao Newman

O Postman CLI é o executor proprietário do Postman. Diferentemente do Newman, ele faz login na conta Postman e pode executar coleções diretamente pelo ID, usando os dados do workspace.

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

Os resultados podem ser enviados de volta para a nuvem do Postman.

Melhor para: equipes que querem manter as execuções ligadas ao workspace na nuvem, sem exportar arquivos JSON.

Limitação: é proprietário e depende de uma conta Postman. A existência de dois executores oficiais também pode gerar dúvidas sobre qual adotar. A comparação Postman CLI vs Newman mostra quando cada opção faz sentido.

5. Bruno CLI: coleções nativas do Git com bru

O Bruno armazena coleções como arquivos .bru em diretórios comuns. As requisições podem ser revisadas, versionadas e executadas como qualquer outro arquivo do repositório.

O CLI é instalado pelo pacote @usebruno/cli e usa o comando bru:

npm install -g @usebruno/cli

# Executa todas as requisições da coleção atual
bru run --env staging

O Bruno oferece asserções e scripts nos próprios arquivos e pode gerar relatórios JSON, JUnit e HTML.

Melhor para: equipes que preferem coleções versionadas no Git, revisadas em pull requests e executadas offline.

Limitação: a autoria em texto puro pode ser menos acessível para equipes mistas, e o ecossistema é mais recente que o do Postman. A comparação Bruno CLI vs Apidog CLI detalha as diferenças.

6. Schemathesis: deixe o esquema gerar os testes

O Schemathesis lê um esquema OpenAPI ou GraphQL e gera casos de teste automaticamente. Ele usa testes baseados em propriedades, construídos sobre o Hypothesis para Python.

Em vez de escrever cada caso manualmente, você pode procurar:

• Respostas 500.
• Violações do esquema.
• Entradas de borda.
• Respostas incompatíveis com o contrato documentado.

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

Melhor para: encontrar bugs que não foram previstos nos testes manuais, especialmente antes de um lançamento.

Limitação: depende de um esquema atualizado e confiável. APIs grandes podem produzir ruído, exigindo filtros, hooks e opções adicionais.

7. Step CI: um arquivo YAML para cada fluxo

O Step CI descreve um fluxo de API em um único arquivo YAML. O arquivo pode conter etapas, valores capturados e verificações.

Ele oferece suporte a REST, GraphQL, gRPC, tRPC e SOAP, além de validação baseada em OpenAPI.

npm install -g stepci

stepci run workflow.yml

Melhor para: fluxos declarativos, como “faça login, capture o token e use-o na próxima requisição”.

Limitação: exige um runtime Node.js. A cadência de lançamentos diminuiu, portanto verifique a atividade recente do repositório antes de adotá-lo em um pipeline crítico.

8. curl: a base disponível em quase todo ambiente

O curl já vem instalado no macOS, na maioria das distribuições Linux e nas versões atuais do Windows. Em ambientes restritos, isso elimina a necessidade de instalar outra ferramenta.

Com -w e scripts de shell, é possível montar um harness mínimo:

# Envia JSON e imprime apenas o status HTTP
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

Melhor para: requisições pontuais, scripts de diagnóstico e ambientes em que novas instalações são bloqueadas.

Limitação: as asserções ficam por sua conta. Você precisa combinar curl com jq, comparações manuais e gerenciamento explícito de códigos de saída. O curl envia e exibe dados; sozinho, não funciona como um executor de testes.

Quando isso deixar de ser suficiente, consulte o guia de alternativas ao curl para teste de API REST.

9. HTTPie e xh: requisições legíveis para exploração manual

O HTTPie torna as requisições no terminal mais legíveis. O comando é http, os campos JSON usam a sintaxe key=value e as respostas são formatadas e coloridas.

O xh oferece uma sintaxe semelhante em Rust, distribuída como um binário único. Ele também possui a flag --curl, que mostra o comando curl equivalente.

http POST api.example.com/users name=acme plan=pro
xh   POST api.example.com/users name=acme plan=pro

Melhor para: explorar uma API manualmente enquanto os testes automatizados são construídos em outra ferramenta.

Limitação: HTTPie e xh são clientes, não executores de testes. Nenhum deles fornece asserções sobre a resposta. O HTTPie usa um runtime Python; o xh oferece um conjunto menor de recursos em troca de inicialização mais rápida.

10. k6: quando a pergunta é capacidade

O k6 responde a uma pergunta diferente: não apenas se a resposta está correta, mas se a API suporta determinada carga.

Ele é um binário Go da Grafana, com scripts em JavaScript. Os thresholds funcionam como critérios de aprovação ou reprovação. Se um limite for violado, o processo termina com código diferente de zero.

brew install k6

k6 run load.js

O arquivo load.js define os usuários virtuais, a duração e os thresholds.

Melhor para: testes de desempenho versionados junto com os testes funcionais e executados em laptops ou pipelines.

Limitação: é uma ferramenta de carga sob AGPL-3.0, não um cliente de testes funcionais. Cenários relevantes exigem familiaridade com a API JavaScript do k6.

Prefere algo interativo?

Clientes TUI, como atac e posting, oferecem editores de requisição completos dentro do terminal. Eles são úteis para explorar APIs, mas não substituem executores que bloqueiam pipelines.

Veja o resumo dos melhores clientes REST API de terminal e TUI.

Tabela comparativa

Ferramenta	Função	Asserções embutidas	Instalação	Código aberto
Apidog CLI	Executar cenários criados visualmente em CI	Sim	npm i -g apidog-cli	Não (camada gratuita)
Hurl	Testes HTTP em texto puro	Sim	brew install hurl	Apache-2.0
Newman	Coleções Postman sem interface gráfica	Sim	npm i -g newman	Apache-2.0
Postman CLI	Execuções Postman vinculadas à nuvem	Sim	Instalador Postman	Não
Bruno CLI	Coleções .bru nativas do Git	Sim	npm i -g @usebruno/cli	MIT
Schemathesis	Fuzzing a partir de um esquema	Geradas	pip install schemathesis	MIT
Step CI	Fluxos YAML de várias etapas	Sim	npm i -g stepci	MPL-2.0
curl	Requisições brutas e scripting	Faça você mesmo	Pré-instalado	Sim
HTTPie / xh	Requisições manuais legíveis	Não	brew install httpie / xh	Sim
k6	Carga com limites de aprovação/reprovação	Limites	brew install k6	AGPL-3.0

Como escolher

Comece pelo trabalho que precisa ser executado:

• Você já usa Postman? Newman ou Postman CLI permitem colocar as coleções existentes no CI rapidamente.
• Quer testes como texto no repositório? Avalie Hurl ou Bruno CLI.
• Tem um esquema OpenAPI confiável? Adicione Schemathesis para gerar casos e encontrar falhas de borda.
• Precisa apenas explorar uma API? Use curl, HTTPie ou xh.
• A pergunta é sobre desempenho? Use k6.
• Quer cenários visuais e execução em vários ambientes? Considere o Apidog CLI.

Escolha o Apidog CLI quando quiser criar cenários em um editor visual e executá-los em laptops, CI e agentes automatizados. O mesmo projeto também pode concentrar design de API, dados mock e documentação. Esse é o trade-off explicado em Apidog CLI: o cliente de API que vive em seu terminal.

Para uma visão mais ampla das camadas de teste, consulte o guia de estratégias de teste de API.

FAQ

Posso testar APIs inteiramente a partir do terminal?

Sim. Crie testes como arquivos, usando Hurl, Bruno ou Step CI, ou use um editor visual, como Apidog e Postman. Depois, execute os cenários sem GUI com o CLI correspondente.

O ponto essencial para o CI é que o executor retorne um código de saída previsível.

Qual é a diferença entre um cliente de API e uma ferramenta de teste?

Um cliente, como curl, HTTPie ou xh, envia uma requisição e mostra a resposta.

Uma ferramenta de teste, como Apidog CLI, Hurl ou Newman, faz asserções e termina com código diferente de zero quando uma validação falha.

Clientes ajudam a explorar. Ferramentas de teste funcionam como gates do pipeline.

Quais ferramentas rodam em pipelines de CI?

Os executores desta lista incluem:

• apidog run
• hurl --test
• newman run
• postman collection run
• bru run
• schemathesis run
• stepci run
• k6 run

Todos retornam código diferente de zero em caso de falha. Para um exemplo de pipeline, veja como executar testes do Apidog CLI no GitHub Actions.

Alguma dessas ferramentas executa testes de carga?

Sim. O k6 é a opção especializada em carga e oferece thresholds para aprovação ou reprovação.

As demais ferramentas verificam principalmente a correção funcional. É comum combinar um executor funcional com k6.

Preciso de uma especificação OpenAPI?

Apenas o Schemathesis exige uma especificação para gerar os testes. Nas outras ferramentas, OpenAPI pode ajudar, mas não é obrigatório.

O Apidog importa OpenAPI 3.x, Swagger 2.0 e coleções Postman. O Step CI também pode validar respostas contra um esquema.

O padrão entre as dez ferramentas é simples: a autoria pode acontecer em uma GUI ou em arquivos, mas a execução precisa funcionar no shell. Escolha onde os testes serão escritos e confirme que o executor retorna um código de saída utilizável pelo pipeline.

Se quiser combinar autoria visual e execução no terminal, baixe o Apidog, crie um cenário no editor e use o comando apidog run no CI.