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

O teste de API saiu da GUI. Os testes agora são executados em contêineres CI sem display conectado, em ambientes de staging que você só acessa via SSH, e sob agentes de IA que falam apenas shell. Nesses três lugares, o terminal é onde um teste passa ou falha sem um humano observando.

Este resumo classifica as ferramentas que realizam um trabalho real de teste a partir de um prompt de shell. "Baseado em terminal" aqui significa que o loop completo é executado em um shell: instala a partir de um gerenciador de pacotes, executa um comando, lê um código de saída. A classificação pesa asserções embutidas, fluxos de várias etapas, relatórios prontos para CI e status de manutenção. Clientes manuais como o curl ainda ganham um lugar perto do final, porque todo fluxo de trabalho de terminal depende deles entre as execuções de teste. Para uma pesquisa mais ampla que inclui 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 de terminal julga a resposta e reporta o veredito como um código de saída que seu pipeline pode usar como gatilho. O segundo grupo é o cerne desta lista, e quatro características o definem:

• Asserções embutidas. Verificações de status, cabeçalhos e corpo pertencem à ferramenta, não a um monte de "cola" jq.
• Códigos de saída que significam algo. Zero em caso de sucesso, não-zero em caso de falha, para que o CI falhe a build para você.
• Repetibilidade. Os testes vivem em arquivos ou projetos que você pode versionar e reexecutar, não em seu histórico de shell.
• Relatórios. Saída que um humano pode ler no terminal e um painel pode analisar como JSON, JUnit ou HTML.

Com os critérios definidos, aqui estão as dez ferramentas que valem seu tempo em 2026.

1. Apidog CLI: crie visualmente, execute sem interface gráfica em qualquer lugar

Apidog é uma plataforma API tudo-em-um que cobre design, testes, mocking e documentação. O Apidog CLI (apidog-cli no npm) é seu braço de terminal. Você constrói cenários de teste no editor visual, com requisições encadeadas, variáveis extraídas e asserções, então apidog run os executa a partir de qualquer shell e entrega ao seu pipeline um código de saída limpo.

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

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

Você não adivinha os IDs. Abra o cenário no Apidog, vá para a aba CI/CD e copie o comando gerado. Os relatores cobrem cli, html, json e junit, escritos em apidog-reports/, para que a mesma execução alimente um terminal, um painel e um armazenamento de artefatos. Execuções orientadas por dados puxam iterações de arquivos CSV ou JSON. A saída é JSON estruturado com agentHints.nextSteps, o que permite que um agente de codificação de IA execute uma suíte e decida seu próximo movimento sem screen-scraping. Ele precisa de Node.js 16 ou posterior.

Melhor para: equipes que desejam cenários complexos de várias etapas criados em um editor e executados identicamente em um laptop, em CI e por agentes. Limitação honesta: não é código aberto e não é um remetente ad-hoc. Os cenários vivem em um projeto Apidog, então esta é a opção de plataforma integrada em vez de uma ferramenta HTTP básica. O guia completo do Apidog CLI abrange todo o conjunto de comandos.

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

Hurl executa requisições HTTP escritas em um formato de texto puro e faz asserções sobre as respostas. Ele é construído em Rust sobre o libcurl e é distribuído como um único binário, então não há runtime para instalar. Os testes se parecem quase com HTTP bruto, o que os torna fáceis de revisar em um pull request.

brew install hurl   # ou: 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

hurl --test login.hurl   # saída não-zero se uma asserção falhar

Melhor para: verificações de estilo de contrato e testes de fumaça que você mantém sob controle de versão como texto legível. A flag --test o torna um portão natural de CI. Limitação honesta: é focado em HTTP, então não irá dirigir gRPC nem gerar carga, e a lógica complexa significa mais arquivos .hurl em vez de uma linguagem de script.

3. Newman: execute coleções do Postman sem interface gráfica

Newman é o executor de linha de comando de código aberto para coleções do Postman (Apache-2.0). Se sua equipe já escreve requisições e testes no Postman, Newman executa essa mesma coleção a partir de um terminal sem GUI. Você exporta a coleção e o ambiente como JSON e aponta Newman para os arquivos.

npm install -g newman

newman run collection.json -e staging.json

Melhor para: equipes que investiram no Postman e querem coleções existentes sendo executadas em um pipeline sem assentos extras. Ele sai com código não-zero quando um teste falha, então o CI bloqueia a build de forma limpa. Limitação honesta: ele executa apenas coleções no formato Postman, e a criação ainda acontece na GUI do Postman. Ele executa testes; não ajuda você a escrevê-los.

4. Postman CLI: a alternativa oficial ao Newman

O Postman CLI é o próprio executor de código fechado do Postman. Ao contrário do Newman, ele faz login em sua conta Postman e pode executar uma coleção por seu ID, diretamente do workspace, com os resultados sendo reportados de volta para a nuvem do Postman.

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

postman collection run <collection_id> -e <environment_id>

Melhor para: equipes Postman que querem execuções ligadas à nuvem sem exportar arquivos JSON. Limitação honesta: é de código fechado e vinculado a uma conta Postman, e ter dois executores oficiais gera confusão real sobre qual adotar. A comparação Postman CLI vs Newman esclarece quando cada um faz sentido.

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

Bruno armazena coleções como arquivos .bru de texto simples em pastas comuns, então as requisições vivem em seu repositório como qualquer outro código. Seu CLI, @usebruno/cli, executa essas coleções a partir do terminal com o comando bru, sem necessidade de conta na nuvem.

npm install -g @usebruno/cli

# Run every request in the current collection folder
bru run --env staging

Melhor para: equipes que desejam coleções revisadas em pull requests e executadas offline, com asserções e scripts tratados nos mesmos arquivos. Ele escreve relatórios JSON, JUnit e HTML para CI. Limitação honesta: a autoria em texto puro agrada mais aos desenvolvedores do que às equipes mistas, e o ecossistema é mais jovem que o do Postman. Veja como ele se compara ao executor do Apidog em Bruno CLI vs Apidog CLI.

6. Schemathesis: seu esquema escreve os testes

Schemathesis segue um caminho diferente: ele lê seu esquema OpenAPI ou GraphQL e gera milhares de casos de teste a partir dele, usando testes baseados em propriedades construídos sobre o Hypothesis do Python. Em vez de escrever cada caso, você o deixa fuzzar entradas para encontrar 500s, violações de esquema e respostas que quebram o contrato que sua documentação promete.

pip install schemathesis

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

Melhor para: pegar bugs de casos de borda que ninguém pensou em escrever um teste, especialmente antes de um lançamento. É um dos argumentos mais fortes para manter um esquema preciso. Limitação honesta: ele precisa de um esquema real para funcionar, e uma API grande pode produzir ruído que você filtrará com hooks e opções.

7. Step CI: um arquivo YAML por fluxo de várias etapas

Step CI descreve um fluxo de trabalho de API em um único arquivo YAML: etapas, valores capturados e verificações. Ele cobre REST, GraphQL, gRPC, tRPC e SOAP em um único fluxo de trabalho e valida contra um esquema OpenAPI. O mesmo arquivo é executado em um laptop e em um pipeline.

npm install -g stepci

stepci run workflow.yml

Melhor para: sequências de login-e-depois-use-o-token descritas declarativamente, sem script. Limitação honesta: ele carrega um runtime Node, e a cadência de lançamento diminuiu, então verifique a atividade recente do repositório antes de construir um pipeline sobre ele.

8. curl: a base que já está instalada

curl vem com macOS, a maioria das distribuições Linux e o Windows atual, então a instalação mais leve é nenhuma instalação. É o cliente de referência contra o qual todas as outras ferramentas se medem, e com -w e cola de shell, pode atuar como um harness de teste mínimo.

# POST 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 e ambientes bloqueados onde nada de novo pode ser instalado. Limitação honesta: as asserções são inteiramente faça você mesmo. Você passa para jq, compara valores manualmente e gerencia códigos de saída na mão. Ele envia e mostra; não testa. O guia alternativas ao curl para teste de API REST aborda o que procurar quando isso não for mais suficiente.

9. HTTPie e xh: requisições legíveis manualmente

HTTPie tornou as requisições de terminal legíveis: o comando é http, os campos JSON são pares key=value, e as respostas vêm coloridas e formatadas. xh reimplementa essa mesma sintaxe em Rust como um único binário estático, com inicialização mais rápida e uma flag --curl que imprime o comando curl equivalente.

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # mesma sintaxe, um binário

Melhor para: explorar uma API manualmente enquanto você constrói os testes reais em outro lugar. Limitação honesta: ambos são clientes, não executores. HTTPie carrega um runtime Python; xh troca um conjunto menor de recursos por velocidade. Nenhum deles faz asserções sobre uma resposta.

10. k6: quando a questão é carga

k6 responde a uma pergunta diferente: não "esta resposta está correta", mas "ela aguenta sob tráfego". É um único binário Go da Grafana, scriptado em JavaScript, com limites que transformam um teste de carga em um gate de aprovação/reprovação. Se um limite for violado, k6 sai com código não-zero, o que o CI interpreta como uma falha.

brew install k6

k6 run load.js   # vus, duration e thresholds definidos no script

Melhor para: verificações de desempenho que vivem no mesmo repositório que testes funcionais e são executadas a partir de um laptop ou um pipeline. Limitação honesta: é uma ferramenta de carga sob AGPL-3.0, não um cliente de teste funcional, e cenários significativos significam aprender sua API JavaScript.

Prefere algo interativo?

Se você deseja uma interface semelhante ao Postman sem sair do shell, essa é uma categoria separada: clientes TUI como atac e posting desenham editores de requisição completos dentro do terminal. Eles exploram APIs; eles não bloqueiam pipelines. O resumo dos melhores clientes REST API de terminal e TUI aborda esse lado em profundidade.

Tabela comparativa

Como escolher

Comece pelo trabalho, não pela ferramenta. Se os testes já existem no Postman, Newman ou o Postman CLI os executa amanhã. Se você quer testes como texto revisável em seu repositório, Hurl e Bruno CLI são as escolhas mais fortes. Se você tem um esquema OpenAPI sólido, adicione Schemathesis e deixe-o caçar os bugs que você não previu. Mantenha curl e xh para a camada manual, e traga k6 no dia em que a pergunta mudar de correção para capacidade.

Escolha o Apidog CLI quando preferir criar cenários em um editor visual e executá-los em todos os outros lugares. É a única opção aqui onde o mesmo projeto também carrega seu design de API, dados mock e documentação, o que é o comércio explicado em Apidog CLI: o cliente de API que vive em seu terminal. Para uma visão mais ampla dos testes por trás dessas escolhas, o guia estratégias de teste de API mapeia onde cada camada se encaixa.

FAQ

Posso testar APIs inteiramente a partir do terminal? Sim. Crie testes como arquivos (Hurl, Bruno, Step CI) ou em um editor visual (Apidog, Postman), e então execute-os sem interface gráfica com o CLI correspondente. Cada executor nesta lista retorna um código de saída, que é tudo o que o CI precisa.

Qual a diferença entre um cliente de API de terminal e uma ferramenta de teste? Um cliente (curl, HTTPie, xh) envia uma requisição e mostra a resposta. Uma ferramenta de teste (Apidog CLI, Hurl, Newman) faz asserções sobre a resposta e falha com um código de saída diferente de zero. Clientes exploram; ferramentas de teste atuam como portões.

Quais destes são executados em pipelines de CI? Todos os executores: apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run e k6 run todos saem com código não-zero em caso de falha. Para um exemplo de pipeline funcionando, veja como executar testes do Apidog CLI no GitHub Actions.

Algum destes lida com testes de carga? k6 é o especialista em carga aqui, com limites como portões de aprovação/reprovação. Os outros verificam a correção, não a capacidade, então muitas equipes emparelham um executor funcional com k6.

Preciso de uma especificação OpenAPI para usar essas ferramentas? Apenas o Schemathesis exige uma, pois ele gera testes a partir do esquema. Em todos os outros casos, uma especificação ajuda, mas não é um bloqueio: Apidog importa OpenAPI 3.x, Swagger 2.0 e coleções Postman, e o Step CI pode validar respostas contra um esquema.

O padrão em todas as dez ferramentas é o mesmo: a autoria busca conforto, a execução busca um shell. Escolha onde você deseja escrever os testes e, em seguida, certifique-se de que o executor entregue um código de saída ao seu pipeline. Se você quiser as duas metades de uma única plataforma, baixe o Apidog, crie um cenário no editor e insira seu comando apidog run no CI para fechar o ciclo.