A maioria dos tutoriais de teste de API aponta você para uma GUI. Mas se você vive no terminal, executa testes em CI, ou quer uma ferramenta cujo código-fonte você possa ler, a linha de comando é onde o teste de API fica interessante. Ferramentas CLI de código aberto oferecem algo que um produto hospedado não pode: uma licença que você pode auditar, um binário que você pode auto-hospedar e um arquivo de configuração que você pode commitar ao lado do seu código.
Esta é uma questão diferente de “qual é a ferramenta mais rápida” ou “qual o menor binário”. Aqui, o foco é licenciamento e controle. Você pode executá-la dentro da sua própria rede sem precisar de uma conta? O código-fonte está no GitHub sob uma licença real aprovada pela OSI? Continuará funcionando se o fornecedor mudar os preços no próximo trimestre? Essas são as perguntas que esta lista responde.
Abaixo estão oito ferramentas CLI gratuitas e com código-fonte disponível para testar APIs REST, GraphQL e HTTP, cada uma com sua licença exata, um comando de instalação real e um comando que mostra seu funcionamento. Se você deseja uma visão mais ampla que inclua ferramentas hospedadas, consulte o resumo das melhores ferramentas gratuitas para teste de API. Para uma abordagem puramente terminal-first sobre como acessar endpoints manualmente, o guia de alternativas ao curl para teste de API REST aborda o lado interativo.
O que torna uma ferramenta CLI “de código aberto” para teste de API
Muitas ferramentas são gratuitas para baixar. Isso não é o mesmo que código aberto. Para esta lista, uma ferramenta se qualifica em três pontos:
- Uma licença real. O código-fonte é público sob uma licença aprovada pela OSI (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD). Você pode lê-lo, fazer um fork e saber o que pode fazer.
- Auto-hospedável, sem conta. Você pode executar tudo na sua própria máquina ou executor de CI sem se inscrever em nada. Sem custo por licença, sem requisito de "phone-home".
- Mantido e inspecionável. O repositório está no GitHub com histórico de commits e issues visíveis, para que você possa julgar se está ativo antes de construir um pipeline com ele.
Cada ferramenta abaixo atende aos dois primeiros pontos. Marquei a que não atende mais ao terceiro. A escolha da licença importa mais do que parece: a AGPL-3.0 (k6) tem obrigações de copyleft se você construir um serviço em torno dela, enquanto MIT e Apache-2.0 são permissivas. Leia a licença antes de incorporar uma ferramenta em um produto.
Hurl: testes HTTP em texto puro, um binário Rust
Hurl executa requisições HTTP escritas em formato de texto puro e faz asserções sobre as respostas. É construído pela Orange-OpenSource em Rust, impulsionado por libcurl internamente, e distribuído como um único binário. Os testes são lidos quase como as próprias requisições, o que os torna fáceis de revisar em um pull request.
Licença: Apache-2.0. Fonte: github.com/Orange-OpenSource/hurl.
brew install hurl # or: cargo install --locked hurl
# login.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
Melhor para: verificações estilo contrato e testes de fumaça que você deseja manter no controle de versão como texto legível. Limitação honesta: é focado em HTTP, então não irá operar gRPC nem gerar carga. Para qualquer coisa além de cadeias de asserções simples, você escreverá mais arquivos .hurl em vez de recorrer a uma linguagem de script.
Step CI: Workflows de API em YAML construídos para CI
Step CI é um executor de workflow configurado em YAML feito para integração contínua. Ele cobre REST, GraphQL, gRPC, tRPC e SOAP em um único arquivo de workflow, e pode realizar testes de carga e validação contra um schema OpenAPI. O executor e a CLI são gratuitos para sempre.
Licença: MPL-2.0. Fonte: github.com/stepci/stepci.
npm install -g stepci
# workflow.yml describes steps, checks, and captures
stepci run workflow.yml
Melhor para: equipes que desejam um arquivo declarativo descrevendo um fluxo de API multi-etapas e executando-o da mesma forma localmente e em CI. Limitação honesta: MPL-2.0 é um copyleft fraco, então se você modificar os próprios arquivos do Step CI, você compartilhará essas mudanças de volta. Usá-lo para testar seu aplicativo não acarreta tal obrigação.
Schemathesis: testes baseados em propriedades a partir do seu schema
Schemathesis lê seu schema OpenAPI ou GraphQL e gera milhares de casos de teste a partir dele, usando testes baseados em propriedades construídos na biblioteca Hypothesis do Python. Em vez de você escrever cada caso, ele "fuzza" as entradas para encontrar erros 500, violações de schema e respostas que não correspondem ao que sua documentação promete.
Licença: MIT. Fonte: github.com/schemathesis/schemathesis.
uv pip install schemathesis # or: pip install schemathesis
schemathesis run https://api.example.com/openapi.json
Melhor para: encontrar bugs de casos extremos para os quais você nunca pensaria em escrever um teste, especialmente antes de um lançamento. É uma das razões mais fortes para manter um schema preciso. Limitação honesta: ele precisa de um schema real para funcionar, e uma API grande pode produzir muito ruído que você desejará filtrar com seus hooks e opções.
Dredd: teste de contrato contra a descrição da sua API
Dredd verifica se sua API em produção realmente corresponde ao seu documento de descrição. Aponte-o para um arquivo OpenAPI (ou API Blueprint) e um backend em execução, e ele reproduz cada requisição documentada e compara a resposta real com a especificação. É agnóstico em relação à linguagem e suporta hooks para configuração e desmontagem.
Licença: MIT. Fonte: github.com/apiaryio/dredd.
npm install -g dredd
dredd apiary.apib http://127.0.0.1:3000
Melhor para: provar que sua documentação e sua implementação não se desalinharam. Limitação honesta, e é uma real: o repositório Dredd foi arquivado em novembro de 2024 e é somente leitura. Ele ainda funciona, mas não é mais mantido, então trate-o como uma ferramenta estável sem futuras correções. Se você quer um verificador dirigido por schema ativamente mantido, Schemathesis é a aposta mais segura.
k6: teste de carga scriptado em JavaScript
k6 é a ferramenta de teste de carga e performance da Grafana. Você scripta os testes em JavaScript ou TypeScript, e um rápido motor Go os executa em escala. É a opção de código aberto ideal quando você precisa saber como sua API se comporta sob centenas ou milhares de usuários virtuais, e não apenas se uma única requisição passa.
Licença: AGPL-3.0. Fonte: github.com/grafana/k6.
brew install k6
k6 new script.js # generates a starter test
k6 run script.js
Melhor para: testes de performance e soak testing que vivem no mesmo repositório que seus testes funcionais. Limitação honesta: AGPL-3.0 é um copyleft forte. Isso é bom para executar testes, mas se você construir e distribuir um serviço em torno do código do k6, a licença tem obrigações reais; leia-a primeiro. k6 também foca em carga, não em asserções de contrato detalhadas.
Newman: execute coleções Postman sem a GUI
Newman é o próprio executor de coleções de linha de comando do Postman. Se sua equipe já tem requisições e testes de API salvos como uma coleção Postman, Newman executa essa coleção exata a partir do terminal ou em CI, sem a necessidade de um aplicativo desktop. É a maneira padrão de integrar um workflow do Postman em um pipeline.
Licença: Apache-2.0. Fonte: github.com/postmanlabs/newman.
npm install -g newman
newman run my-collection.json -e staging-environment.json
Melhor para: equipes com coleções Postman existentes que desejam execuções em CI sem pagar por licenças extras do Postman. Limitação honesta: está vinculado ao formato de coleção do Postman, então você cria os testes na UI do Postman (ou em seu JSON) em vez de um arquivo de configuração simples. Ele executa coleções; não projeta ou simula APIs.
Tavern: testes de API como um plugin pytest
Tavern é uma biblioteca Python, CLI e plugin pytest que descreve testes de API em YAML. Por se integrar ao pytest, você obtém todo o ecossistema pytest gratuitamente: fixtures, relatórios, paralelismo e integrações de CI que você já pode usar. Ele lida com REST, MQTT e gRPC.
Licença: MIT. Fonte: github.com/taverntesting/tavern.
pip install tavern
# test_login.tavern.yaml sits next to your other tests
pytest test_login.tavern.yaml
Melhor para: equipes Python que já usam pytest e desejam que os testes de API vivam lado a lado com os testes unitários. Limitação honesta: ele assume que você se sente confortável em uma configuração de teste Python. Se sua stack não é Python, a dependência do pytest é um atrito em vez de um recurso.
Venom: testes de integração multi-executores da OVHcloud
Venom, da OVHcloud, executa testes de integração em muitos tipos de executores: requisições HTTP, scripts shell, IMAP, web, bancos de dados e mais. É escrito em Go, usa suítes de teste YAML e emite arquivos de resultado xUnit que os sistemas de CI leem nativamente. Ele se destaca quando um único teste precisa tocar mais do que apenas um endpoint HTTP.
Licença: BSD (modificada). Fonte: github.com/ovh/venom.
# download the binary from GitHub releases, then:
venom run testsuite.yml
Melhor para: fluxos ponta a ponta que misturam uma chamada de API com uma verificação de banco de dados ou um passo de script em uma única suíte de testes. Limitação honesta: com tantos executores, o YAML fica verboso, e a documentação assume que você montará exemplos a partir do repositório.
Onde Apidog se encaixa (e uma nota honesta)
Aqui está a parte honesta. Apidog não é de código aberto. É um produto comercial com um nível gratuito, então não pertence a uma lista de ferramentas com código-fonte disponível. Mas vale a pena conhecê-lo por uma razão: as ferramentas acima fazem cada uma um trabalho, e juntar Hurl mais Schemathesis mais Newman mais um mock server em um workflow coerente é um trabalho real que você terá que manter por conta própria.
Apidog integra design, teste, mocking e documentação em uma única plataforma, e apidog-cli traz o lado dos testes para o terminal. Você cria cenários de teste uma vez e depois os executa em CI com um único comando:
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN> # exits 0 on all-pass, non-zero on failure
A saída é um JSON estruturado com agentHints.nextSteps, o que facilita a criação de scripts ou a entrega a um agente de IA. O guia completo do apidog-cli detalha o conjunto completo de comandos. Então: não é código aberto, mas o nível gratuito mais a CLI oferece uma alternativa integrada para conectar várias ferramentas de propósito único. Se uma licença que você pode auditar é um requisito rigoroso, escolha uma das oito acima. Se um workflow integrado importa mais, esta é a troca.
Como escolher
| Ferramenta | Melhor para | Instalação | Código aberto? | Licença |
|---|---|---|---|---|
| Hurl | Asserções HTTP em texto puro no Git | brew install hurl |
Sim | Apache-2.0 |
| Step CI | Workflows de CI declarativos | npm i -g stepci |
Sim | MPL-2.0 |
| Schemathesis | Fuzzing baseado em propriedades a partir de um schema | pip install schemathesis |
Sim | MIT |
| Dredd | Testes de contrato doc-vs-implementação | npm i -g dredd |
Sim (arquivado) | MIT |
| k6 | Testes de carga e performance | brew install k6 |
Sim | AGPL-3.0 |
| Newman | Execução de coleções Postman em CI | npm i -g newman |
Sim | Apache-2.0 |
| Tavern | Testes de API dentro do pytest | pip install tavern |
Sim | MIT |
| Venom | Suítes de integração multi-executor | Lançamentos do GitHub | Sim | BSD |
| apidog-cli | Workflow integrado de design a teste | npm i -g apidog-cli |
Não (plano gratuito) | Comercial |
Combine a ferramenta com a tarefa. Escolha Hurl ou Newman quando quiser verificações de requisição rápidas e legíveis; Schemathesis quando tiver um schema e quiser que bugs sejam encontrados para você; k6 quando a questão for escala; Tavern ou Venom quando os testes precisarem viver em uma suíte maior. Se você estiver comparando estas ferramentas com um processo maior, o guia de estratégias de teste de API aborda onde cada tipo se encaixa, e o artigo sobre ferramentas de teste de API headless analisa a execução de testes sem nenhuma UI.
Concluindo
Ferramentas CLI de código aberto oferecem testes de API que você pode ler, forkar e executar em seus próprios termos. Hurl e Newman lidam com verificações de requisição diárias, Schemathesis e Dredd impõem seu contrato, k6 impulsiona o desempenho, e Tavern e Venom integram testes de API em suítes mais amplas. Escolha pela licença e pela tarefa específica que você precisa realizar; nada o impede de executar duas delas.
Quando você preferir projetar, testar, simular e documentar em um só lugar em vez de manter uma cadeia de ferramentas, Apidog cobre todo o ciclo de vida e oferece o apidog-cli para CI. Baixe Apidog para experimentar a CLI ao lado das ferramentas acima e ver qual combinação se adapta ao seu pipeline.
