Hurl - ferramenta baseada em texto para requisições e testes HTTP na linha de comando

(github.com/Orange-OpenSource)

27 pontos por GN⁺ 2025-06-21 | 3 comentários | Compartilhar no WhatsApp

Executa requisições HTTP com um formato simples de arquivo de texto e é uma ferramenta de linha de comando open source que permite encadear várias requisições, extrair valores e consultar/validar corpo e cabeçalhos da resposta
Suporta diversas APIs e requisições baseadas em REST, SOAP, GraphQL e HTML/XML/JSON, sendo adequada tanto para consulta de dados quanto para testes de sessão HTTP
Permite encadear requisições, capturar valores e validar código de status, cabeçalhos, corpo e muito mais, sendo vantajosa para integração com CI/CD e automação com relatórios JUnit, TAP, HTML e JSON
Distribuída como um executável único implementado em Rust, tem instalação simples e usa internamente o motor libcurl para oferecer alta velocidade e forte compatibilidade de protocolos
É avaliada como uma ferramenta moderna de automação de testes HTTP, com sintaxe concisa e extensibilidade em comparação com ferramentas concorrentes
Como open source guiado pela comunidade, mostra alta utilidade tanto para desenvolvedores quanto para equipes de DevOps graças ao seu formato intuitivo e extensível baseado em texto

What's Hurl?

Hurl é uma ferramenta que permite escrever requisições HTTP em um formato de texto claro e intuitivo para executá-las na linha de comando
Permite encadear várias requisições como uma sequência, extrair valores das respostas e usar várias consultas (cabeçalhos, corpo, código de status etc.) para testar cenários HTTP complexos
Baseada no motor libcurl, oferece alta confiabilidade e suporte a protocolos modernos como IPv6 e HTTP/3
Suporta consulta de dados, testes de cenário e medição de desempenho (como tempo de resposta)
É otimizada para geração de relatórios (JUnit, TAP, HTML etc.) e integração com pipelines de CI/CD
Atende a diversas APIs como REST, SOAP, GraphQL, HTML, XML e JSON, e também suporta parsing de corpo (ex.: XPath, JSONPath)
A seguir, alguns diferenciais importantes do Hurl em relação a outras ferramentas de teste HTTP (ex.: Postman, curl):
- Pode ser escrito em texto puro, facilitando versionamento e colaboração
- Fornece um binário único e leve, escrito em Rust, sem necessidade de runtime adicional
- Baseado no mesmo motor de rede do curl (libcurl), com confiabilidade e suporte a vários protocolos
- Suporta diversos formatos como REST, SOAP, GraphQL e HTML, além de permitir configurar cenários complexos
- Integração fácil com CI/CD, automação de testes e relatórios detalhados (JUnit, HTML, TAP etc.)

Resumo dos principais recursos

Funcionamento básico
- Executa várias requisições HTTP escritas sequencialmente dentro de um arquivo Hurl (.hurl)
- Permite extrair valores da resposta de cada requisição, validar condições e passar dados para a próxima requisição
- Compatível com vários formatos, como REST/JSON, SOAP/XML, GraphQL e HTML
Encadeamento e uso de variáveis
- Permite escrever várias requisições em cadeia dentro de um único arquivo
- Usa a sintaxe de Captures para extrair valores das respostas e injetá-los como variáveis em requisições posteriores
- Faz extração e uso de dados por meio de XPath, JSONPath, expressões regulares e estrutura do corpo
Diferentes formas de requisição e validação
- Suporta configuração de vários detalhes da requisição, como parâmetros de query, cabeçalhos e autenticação
- Usa a sintaxe [Asserts] ou sintaxe implícita para validar código de status, corpo, cabeçalhos, cookies, tempo de resposta, hash e mais
- Permite usar XPath e JSONPath, além de testar conteúdo REST/GraphQL/SOAP e HTML
- Suporta validação de múltiplos valores, propriedades do corpo/hash/certificado, atraso de requisição/resposta e tratamento de dados binários
Relatórios de teste e integração com automação
- Exporta os resultados da execução em vários formatos de relatório, como texto, HTML, JUnit, TAP e JSON
- Pode ser integrado facilmente a pipelines de CI/CD
Controles avançados e recursos úteis
- Transferência de dados entre requisições (captura e parametrização)
- Funções de geração de dados dinâmicos (newUuid, newDate etc.)
- Customização de opções por requisição
- Polling/retry, atraso entre requisições, skip e mascaramento de valores sensíveis (redact)
- Suporte às mesmas opções do curl (é possível usar as opções do curl diretamente)
- Recursos nativos voltados para nuvem, como autenticação AWS Sigv4

Exemplos de uso

Defina requisições GET/POST simples e encadeamento de múltiplas etapas em um arquivo de texto simples
- Crie o arquivo sample.hurl e execute o comando $ hurl sample.hurl para rodar todas as requisições de uma vez

Exemplo:

  GET https://example.org  
  HTTP 200  
  [Captures]  
  csrf_token: xpath &quot;string(//meta[@name='_csrf_token']/@content)&quot;  

  POST https://example.org/login?user=toto&amp;password=1234  
  X-CSRF-TOKEN: {{csrf_token}}  
  HTTP 302

Permite testar vários endpoints de API e comparar valores de resposta, usar valores encadeados (como tokens) e validar código de status, cabeçalhos e dados do corpo

Casos de uso representativos

Testes de diversas APIs como REST/GraphQL/HTML/JSON/SOAP
Extração e reutilização de valores como token CSRF, autenticação e autorização
Validação detalhada de código de status, cabeçalhos, dados do corpo, cookies e certificados SSL
Automação e monitoramento de cenários reais de serviço (login~execução de tarefas etc.)
Suporte multiplataforma e a vários métodos de instalação (Linux, macOS, Windows, Docker, npm, Cargo etc.)

Principais opções de CLI

--test: modo de teste (exibe resumo e relatório)
--report-html, --report-json, --report-junit, --report-tap: suporte a vários formatos de relatório
--parallel, --jobs N: execução paralela
--retry, --retry-interval: nova tentativa automática/espera
-u, --user: entrada de credenciais de autenticação
--variable, --variables-file: definição de variáveis
-o, --output: salva a resposta em arquivo
--json: exibe o resultado da execução em formato JSON

Como instalar

Pode ser instalado de várias formas, como Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker e npm
Por ser um binário único, não requer runtime adicional

Ex.:

brew install hurl

cargo install --locked hurl

Vantagens em relação a ferramentas concorrentes

Mais vantajoso que ferramentas GUI como Postman e Insomnia para abordagem baseada em texto, controle de versão e integração com CI/CD
Mais especializado que o curl em testes, execução de cenários, validação e automação de relatórios
Tem curva de aprendizado menor do que DSLs complexas como YAML e JSON, graças ao seu formato próprio intuitivo

3 comentários

seunggi 2025-07-04

Bruno - cliente de API open source rápido e amigável ao Git (alternativa ao Postman)
https://pt.news.hada.io/topic?id=13730

xguru 2025-06-21

Lançamento do Hurl 4.0.0
Há 2 anos era a versão 4.0, mas agora já está na 6.1.1.

GN⁺ 2025-06-21

Comentários do Hacker News

Comecei a usar o hurl nos últimos meses.
Gosto bastante do fato de poder usar tanto o modo de suíte de testes quanto o modo de chamadas individuais.
Uso para executar suítes de teste de requisições HTTP no CI.
Acho que a linguagem de configuração em blocos não é muito intuitiva, e a documentação sobre as assertions suportadas parece um pouco insuficiente.
No geral, a ferramenta em si entrega bastante valor.
Comecei a testar interfaces ao trabalhar em POCs e percebi que essa abordagem pode ajudar no desenvolvimento com base em LLMs.
Ao escrever os testes diretamente nos métodos HTTP, testes e implementação ficam separados de forma mais flexível ao longo da evolução do projeto.
Essa separação dos testes também deixa mais clara a fronteira entre interface e implementação.
Antes de adotar o hurl, eu escrevia os testes no framework de testes da linguagem do serviço, mas os testes baseados em hurl me fazem manter rigorosamente a “perspectiva do cliente”.
Sem acesso indireto aos dados nem nada do tipo, interface, testes e implementação ficam totalmente separados, o que dá bastante segurança.
- Sou o desenvolvedor do hurl.
  Obrigado pelo feedback.
  Quando comecei o desenvolvimento, há 6 ou 7 anos, tentei primeiro JSON e depois YAML, mas aos poucos fiquei convencido de que deveria criar um novo formato de arquivo.
  Entendo perfeitamente que isso pode soar estranho do ponto de vista do usuário.
  Tentei aplicar uma sintaxe simples aos casos mais simples, mas talvez não tenha ficado perfeito.
  Quanto à documentação, se houver pontos fracos ou melhorias possíveis, espero receber opiniões e continuar aprimorando.
O Hurl é uma ferramenta realmente excelente.
Quando fiz a migração de um serviço web escrito em Python para Rust, testes rigorosos da API pública ajudaram muito.
Graças a um ambiente de testes de integração independente da linguagem, foi possível manter a API e o site como estavam e trocar apenas o backend.
Há mais uma vantagem específica ao usar Hurl com Rust.
Dá para integrar com cargo test, usar diretamente a biblioteca do hurl e reutilizar os arquivos .hurl sem mudanças.
Demo: https://github.com/perrygeo/axum-hurl-test
Comecei a usar Hurl em setembro de 2023.
Antes eu executava suítes de teste com o Runscope, mas me incomodava muito o fato de as alterações não ficarem sob controle de versão.
Fiz o trabalho inicial e migrei para Hurl, abandonando o Runscope.
Agora consigo ver rapidamente quem mudou o quê, quando e por quê, e estou bem satisfeito com isso.
- Eu também odiava o fato de as mudanças no Runscope não ficarem sob controle de versão.
  Nosso time também tentou resolver esse problema e o projeto acabou perdendo ritmo.
Acho a ideia em si boa, mas fico pensando “por que eu usaria isso?”.
Eu desenvolvo com Django, e os recursos de teste nativos do framework já são muito completos.
Adotar uma ferramenta externa que não conhece meu próprio backend parece só aumentar o custo de sincronização.
E, se algo estiver estranho, eu também não conseguiria simplesmente entrar no depurador na mesma hora.
Existe o argumento de que testes e código de backend devem ficar claramente separados, mas na prática isso aumenta o custo de manutenção.
No fim, eu ainda precisaria rodar a suíte de testes nativa, então usar várias ferramentas externas em paralelo parece meio estranho.
Dito isso, talvez faça sentido para validar o quão genérica é a API.
- Também pensei bastante nessa pergunta: por que usar uma ferramenta que não conhece meu backend e só aumenta o trabalho de sincronização?
  Nunca usei hurl, mas já usei várias ferramentas para testar APIs de forma independente da linguagem e também estou desenvolvendo uma.
  O que me faz achar esse tipo de ferramenta interessante é o seguinte:
  - O fato de não conhecer a implementação interna acaba sendo uma vantagem.
    Como valida apenas entrada e saída, não depende da lógica interna.
  - Por ser independente de linguagem, dá para compartilhar com outros times e até usar como documentação, ou no lugar de uma especificação OpenAPI.
  - Como testa o próprio contrato da API, também pode ser reutilizada em grandes migrações.
    Por exemplo, ao migrar uma API pública de Perl para Go, dá para usar a API em Perl como teste de não regressão e rodar exatamente os mesmos testes na API em Go, o que aumenta bastante a confiança.
  - Quando o desenvolvedor escreve esse tipo de teste, consegue mudar temporariamente para a perspectiva de consumidor da API, o que ajuda a escrever testes de melhor qualidade.
- Dá para ver isso como uma alternativa a produtos como Postman.
  Não precisa abrir uma janela pesada baseada em Electron só para testar algumas requisições HTTP simples.
  Fica em algum ponto entre scripts com curl e Postman, sendo ideal para quem quer leveza e praticidade ao mesmo tempo.
- Nós usamos Hurl ao migrar de um servidor web com ktor para um código baseado em spring boot, numa stack Java/Kotlin.
  Como dava para manter uma suíte de testes no nível da especificação, independentemente da stack do servidor, a transição foi muito tranquila.
  Além disso, usamos imagens Docker em produção, e com Hurl conseguimos fazer testes de integração de forma bem leve e independente, em vez de depender de ferramentas excessivamente acopladas à implementação.
A seção de exemplos (https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) parece muito convincente para quem quer entender os pontos fortes da ferramenta em 5 minutos, ou seja, para pessoas que tendem a julgar antes de experimentar.
Eu mesmo às vezes sou desse tipo, e achei realmente impressionante.
Sou o mantenedor do Hurl.
Perguntas e feedback são sempre bem-vindos.
- Um padrão que eu e muitos desenvolvedores ao meu redor usamos é escrever testes em arquivos ".http" executáveis por extensões de IDE do VS Code ou do IDEA.
  Um formato de exemplo é:
```
POST http://localhost:8080/api/foo
Content-Type: application/json
{ "some": "body" }
```
  Depois fazemos o teste de integração comparando a saída 1:1 com um arquivo expected.json.
  Executamos esses arquivos com cURL e scripts bash sob medida, comparamos os resultados com jq e registramos sucesso/falha no console.
  Fico curioso para saber se com Hurl também dá para definir, na IDE, requisições HTTP de exemplo e resultados esperados baseados em arquivos JSON desse jeito.
  E também queria saber se o Hurl consegue executar automaticamente vários arquivos dentro de uma pasta.
- O Hurl é subestimado no que diz respeito a permitir escrever suítes de teste em nível HTTP de um jeito bonito e fácil de manter.
  Obrigado por desenvolver uma ferramenta assim.
- Fiquei muito satisfeito com o nome Hurl.
  Achei muito boa a sacada de quem criou.
- Usei Hurl por um tempo e até contribui com o projeto.
  Gostaria de saber como está a possibilidade de oferecer um recurso de include.
- Obrigado por manter o projeto de forma contínua.
  Como você enxerga a visão e o futuro do Hurl daqui a 2 anos?
Tirei muita inspiração deste projeto e acabei desenhando minha própria ferramenta de testes HTTP.
Precisávamos executar centenas de testes em paralelo com rapidez e, se você gostou do Hurl, talvez também ache interessante a ferramenta Nap.
- Fiquei curioso para saber se a sintaxe ou o conteúdo de configuração é igual ao Hurl, e em que pontos difere.
  Se houver uma página resumindo as diferenças, gostaria de vê-la.
Parece interessante.
Eu usei Vscode-restclient por muito tempo, mas recentemente venho migrando para o httpyac para scripts e uso em CLI.
Também pretendo ver se o Hurl atende ao que eu procuro.
Uma das coisas incômodas ao usar ferramentas de teste é que ainda não existe um padrão, em arquivos .http, para referenciar o resultado de uma requisição como entrada da próxima.
As três ferramentas que usei até agora fazem isso de formas diferentes.
- hurl usa [Captures]
- Vscode-restclient referencia o nome da requisição na declaração de variáveis
- httpyac usa a sintaxe @ref
  Como cada uma tem uma sintaxe diferente, o que você escreve para uma ferramenta quebra nas outras.
  Links de referência relacionados:
  documentação de captura do hurl
  Vscode-restclient
  documentação do ref no httpyac
- Desculpe por criar mais um formato de arquivo!
  Uma forma de aliviar um pouco esse problema é usar o hurlfmt.
  O hurlfmt permite exportar arquivos Hurl para JSON.
  Você pode usar esse resultado em JSON para criar conversões para outras ferramentas.
  Não é uma solução mágica e perfeita, mas pode ajudar um pouco ao migrar do Hurl para outros formatos.
- Tanto o Visual Studio Code quanto o Visual Studio têm suporte a arquivos .HTTP, mas eles não são compatíveis entre si.
  Achei interessante como isso parece um caso real da Lei de Conway.
Parece um pouco parecido.
https://marketplace.visualstudio.com/items?itemName=humao.rest-client
Essa extensão do VS Code é muito poderosa para testes relacionados a HTTP.
- A grande diferença é que dá para usar independentemente do editor, e isso é enorme.
- O IntelliJ também tem um recurso parecido.
  https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html
- Eu também usei Hurl e achei bem bom.
  Mas recentemente passei a preferir mais a abordagem com .http.
  Ela já vem embutida no IntelliJ, existe o plugin linkado acima e, no CLI, também usei httpYac.
  Não há vendor lock-in e também é muito fácil compartilhar por controle de versão ou por copiar e colar.
Na JVM, eu faço testes de integração com Karate.
https://github.com/karatelabs/karate
Como ele permite incluir JavaScript arbitrário, dá para escrever requisições e validações com bastante flexibilidade.

Hurl - ferramenta baseada em texto para requisições e testes HTTP na linha de comando

What's Hurl?

Resumo dos principais recursos

Funcionamento básico

Encadeamento e uso de variáveis

Diferentes formas de requisição e validação

Relatórios de teste e integração com automação

Controles avançados e recursos úteis