Lanzamiento de Hurl 4.0.0

• Hurl 4.0.0 es una nueva versión de la herramienta CLI de pruebas HTTP basada en curl, que mejora el flujo para ejecutar solicitudes HTTP y validaciones de respuestas escritas en archivos de texto plano
• El reporte HTML se genera como HTML puro usando solo CSS inline y sin JavaScript, y muestra en conjunto una línea de tiempo tipo waterfall por solicitud/respuesta, registros de ejecución y errores inline
• --error-format long imprime los headers y el cuerpo de la respuesta de las pruebas fallidas, para que en la depuración de CI/CD se pueda revisar el contexto necesario para identificar la causa sin volver a ejecutar
• Con los nuevos filtros decode y xpath, se pueden decodificar directamente bytes de respuesta cuyo charset no está claro y realizar validaciones XPath sobre partes de HTML
• Cambió parte de la forma de evaluar JSONPath, y se admite el uso de métodos HTTP personalizados que cumplan la condición de ir en mayúsculas, por lo que también se pueden probar métodos nuevos como QUERY

---

Resumen de Hurl 4.0.0

• Hurl es una herramienta de línea de comandos basada en curl que ejecuta solicitudes HTTP definidas en un formato simple de texto plano
• En un archivo de Hurl se pueden escribir tanto las solicitudes como el estado HTTP esperado y las validaciones (asserts) de headers, certificados o JSONPath
• Hurl 4.0.0 se centra en cambios relacionados con reportes HTML, salida de errores, filtros, comportamiento de JSONPath y soporte para métodos HTTP personalizados

Reportes HTML y línea de tiempo waterfall

• El reporte HTML de Hurl genera tres tipos de información en cada ejecución
  • Línea de tiempo waterfall: muestra cada solicitud/respuesta en forma de gráfico y permite revisar tiempos de respuesta como DNS, handshake TCP y time to first byte
  • Registro de ejecución: incluye headers de solicitud/respuesta e información de certificados
  • Archivo fuente con resaltado de sintaxis: muestra los errores inline
• El reporte está compuesto por HTML puro y CSS inline, sin JavaScript, por lo que es fácil de integrar en entornos de CI/CD como GitLab CI/CD o GitHub Actions
• Los tiempos usados en la línea de tiempo waterfall los proporciona libcurl, y también se exponen mediante la opción --json
  • --json ofrece información estructurada de la ejecución, incluidos errores, asserts, certificados, capturas, cookies y tiempos
  • Con esta salida JSON se pueden crear reportes propios

Cuello de botella de rendimiento en asserts revelado por la visualización

• Una visualización rica puede sacar a la luz problemas de rendimiento ocultos
• En algunas ejecuciones aparecieron grandes intervalos entre solicitudes, y la causa fue la enorme cantidad de asserts sobre respuestas HTTP
• En Hurl 4.0.0, el cálculo de asserts funciona con un enfoque simple
  • Cada assert de una misma respuesta se procesa de forma independiente
  • En cada assert se vuelve a parsear y recalcular todo desde el inicio
• El equipo de Hurl confiaba en la velocidad de la combinación de libcurl y Rust, pero este caso los llevó a concluir que en la siguiente versión será necesario mejorar el rendimiento de los asserts

Salida de errores detallada para CI/CD

• La salida anterior ante fallas de pruebas se centraba en el valor esperado, por lo que podía faltar información necesaria para el análisis
• Con la nueva opción --error-format, se puede elegir una descripción de error más extensa
• En el modo --error-format long, los headers de la respuesta y el cuerpo de la respuesta se registran automáticamente en el log
• En el ejemplo, la prueba buscaba el header Control-Security-Policy, pero la respuesta real contenía Content-Security-Policy
  • Como los headers y el cuerpo de la respuesta quedan incluidos en el log, es fácil detectar este tipo de error por typo
• Esta opción es útil en entornos de CI/CD donde se quiere obtener el contexto necesario para depurar una sesión sin volver a ejecutar la prueba
• Como también se registra el cuerpo de la respuesta, el log puede volverse muy largo

Nuevos filtros: decode y xpath

• Los asserts de texto de Hurl decodifican automáticamente los bytes del cuerpo de la respuesta usando como pista el charset del header de respuesta Content-Type
• Hay casos donde Content-Type no incluye codificación, o donde el charset aparece dentro de una etiqueta <meta> del documento HTML
• El nuevo filtro decode permite decodificar explícitamente bytes a texto para validarlos
  • El ejemplo decodifica un cuerpo codificado en GB2312 con bytes decode "gb2312"
• El nuevo filtro xpath permite evaluar expresiones XPath sobre partes de una respuesta
  • El ejemplo valida el texto del body HTML con xpath "string(//body)"

Cambios en la evaluación de JSONPath

• Hurl 4.0.0 cambia parte de la evaluación de consultas JSONPath
• JSONPath no cuenta con una especificación oficial adecuada, y Hurl intenta seguir lo más posible la documentación de goessner.net, usada de facto como estándar
• Existen casos límite que varían según la implementación
  • El JSONPath estándar siempre devuelve colecciones, pero eso muchas veces no aporta mucho significado y puede dificultar las pruebas
  • Algunas implementaciones distinguen entre el valor de nodo de un definite path y la colección de un indefinite path
• En Hurl 4.0.0, solo hay dos tipos de selector que devuelven valores
  • Selector de índice de arreglo: $.store.book[2]
  • Selector de clave de objeto: $.store.bicycle.color, $.store.bicycle['color']
• Los selectores con filtros o selectores como $[*].id devuelven una colección
  • Para extraer un valor de una colección, se puede usar el filtro nth

Métodos HTTP personalizados

• Hurl 4.0.0 admite métodos HTTP personalizados arbitrarios
• Los métodos deben escribirse en mayúsculas
• Como ejemplo, ya se puede probar de inmediato el nuevo método QUERY
  • Documentación relacionada: incoming new QUERY method

Notas de lanzamiento y solicitud de participación

• El resto de mejoras y correcciones de errores puede revisarse en las release note
• El proyecto pide apoyo con stars en GitHub, difusión en Twitter, solicitudes de mejoras y compartir casos de uso

[GN⁺]

Comentarios de Hacker News

• Me gustó que la presentación de Hurl empezara con “una herramienta de línea de comandos basada en curl que ejecuta solicitudes HTTP definidas en un formato simple de texto plano”
  Era la primera vez que veía Hurl, pero con solo la breve introducción y el ejemplo de código de arriba ya me dieron ganas de instalarlo y probarlo; parece un excelente lanzamiento

  • Como mantenedor de Hurl, llevo mucho tiempo leyendo Hacker News y fui anotando todos los consejos de presentación como “muestra ejemplos del lenguaje lo antes posible” y “explica el concepto de forma concisa cada vez”, y traté de reflejarlos realmente en hurl.dev
  • Demasiados anuncios y README empiezan hablando de requisitos de instalación o de que “arreglamos X, Y y Z”, pero nunca explican qué hace la herramienta; este enfoque sí es el correcto
  • Es cierto, aunque la mayor parte de eso debería haber estado en el título del post
    Por ejemplo, un título como Hurl: Run HTTP requests in a simple plain-text format habría sido mejor

• Ojalá esto se convierta en el estándar de la industria para pruebas de API
  Ya me cansé de ver capturas de pantalla de Postman enviadas por QA, y de esperar a que QA presione Send después de un cambio; seguro que QA también ya se cansó de esperar a los desarrolladores
  Hurl parece no tener razón para no usarse donde sea posible, porque tanto desarrolladores como QA pueden leerlo y escribirlo, permite automatización e integración con CI, facilita comunicar el comportamiento esperado y puede incluirse en los PR como punto de partida para QA

  • En un servicio estamos usando Hurl para pruebas manuales de API y en CI, y va bastante bien
    Puedes poner todo el flujo de intercambios HTTP de cada workflow en un solo archivo hurl, y se convierte en un suite de pruebas que entra directo a Git
  • Si tu equipo usa VSCode, también pueden probar vscode-restclient: https://github.com/Huachao/vscode-restclient
    Aun así, Hurl también es muy interesante, y coincido en que no depender del editor es una mejor solución para este problema
  • Me pregunto si también has usado https://k6.io/
    Permite escribir pruebas de carga/rendimiento en JS, hacer commit al repositorio, automatizarlas fácilmente en CI, enviar métricas a varios backends, usar protocolos además de HTTP, y ofrece una interfaz moderna de línea de comandos con muchas funciones
    También hay un convertidor de Postman a k6: https://github.com/apideck-libraries/postman-to-k6
    La filosofía de k6 es que los desarrolladores escriban este tipo de pruebas como hacen con pruebas unitarias/de integración, para romper el ciclo clásico entre QA y desarrollo. Hurl también se ve bien, pero parece más limitado en funciones que las herramientas de pruebas de rendimiento ya existentes, y personalmente prefiero escribir las pruebas en un lenguaje de programación en lugar de un formato de texto dedicado
  • Personalmente me gusta el enfoque de definir todo con OpenAPI y luego validar la especificación con Dredd
    Incluso si usas herramientas que generan la especificación desde el código fuente, sigue siendo posible cometer errores de usuario al definir mal los metadatos del endpoint, y Dredd los detecta

• Está muy cerca de ser el mejor ejemplo de un programa Unix moderno que he visto hasta ahora
  Acepta entrada estándar, escribe en salida estándar, no llena la terminal de emojis Unicode por todos lados, y además tiene páginas man bastante buenas
  También me gusta que la extensión de archivo de hurl tenga cuatro letras en vez de tres; por fin parece haberse librado de la compatibilidad con MS-DOS
  Se ve como una herramienta que vale la pena usar en serio

  • No me había dado cuenta de cuánto me molestaban los emojis en la terminal, pero ahora que dicen que esta herramienta no los tiene, de pronto me alegra
  • Ya no solo se libró de la compatibilidad con MS-DOS, sino también de la compatibilidad con VMS

• Para herramientas de línea de comandos para trabajar con HTTP, mis favoritas son Httpie o XH, que es una reescritura más rápida en Rust
  Te permiten enviar solicitudes desde la línea de comandos con una sintaxis mucho más cercana a HTTP que curl, sin tener que aprender muchas opciones
  Si ya estás acostumbrado a curl quizá no te sirvan tanto, pero para un uso casual son mucho más intuitivas
  https://httpie.io/
  https://github.com/ducaale/xh

• En Adaptive estamos usando hurl.dev ampliamente para automatización de pruebas: https://adaptive.live
  Probamos con Hurl todo el flujo interno del producto, y ha sido una de las mejores decisiones que hemos introducido en la organización en términos de estabilizar el producto
  Antes de cada despliegue ejecutamos varias pruebas automatizadas basadas en Hurl para validar onboarding, registro, flujos principales y más, y como está contenedorizado también puede ejecutarse en paralelo
  También estamos creando herramientas internas alrededor de hurl.dev, y nos gusta que sea fácil de aprender, de modo que analistas o usuarios de negocio también puedan crear pruebas

  • Me da curiosidad por qué usan una herramienta independiente
    En el contexto de pruebas, un enfoque basado en navegador como Selenium parece mucho más potente y útil en general
  • Me pregunto si soporta flujos OAuth de forma nativa, o si requiere tokens hardcodeados
    Revisé la documentación pero no encontré nada al respecto

• Llevo un tiempo observando hurl, y lo que lo diferencia de otras herramientas es que tiene su propio DSL para pruebas
  No solo envía solicitudes HTTP, también puede validar respuestas y capturar datos
  Pero si el mantenedor está leyendo esto, me gustaría que permitiera delegar validaciones a scripts externos
  Por ejemplo, si quieres validar que todas las propiedades de una colección de elementos tengan el mismo valor, sigue siendo difícil sin usar el selector nth, y también haría falta algo como nth = *
  Dar cobertura a todos los casos de uso con el DSL es un trabajo enorme, así que estaría bien poder pasar el resultado de jsonpath a jq y hacer que la prueba pase si devuelve true

  • Un DSL inevitablemente termina creciendo poco a poco hacia un lenguaje de propósito general Turing completo, así que llamar scripts externos parece razonable
    Aunque hacerlo también podría volver los archivos menos autocontenidos y generar problemas bastante complejos

• Hurl parece estar creciendo rápido, y eso se ve bien
  En las pruebas de endpoints siempre hace falta autenticación, así que me pregunto si hay alguna forma de escribir la autenticación en un archivo y luego importarla al inicio de otros archivos que necesiten el token

  • Parece que Hurl no tiene funciones como include o macros
    De todos modos, tampoco está claro que esa sea la mejor forma de guardar y usar secretos
    Según la documentación, se pueden pasar variables a los archivos hurl mediante argumentos de línea de comandos y variables de entorno: https://hurl.dev/docs/templates.html

• Para este caso de uso también me gusta bastante httpyac: https://httpyac.github.io
  Tiene funciones de scripting en JS, así que es bastante parecido, y además de la interfaz de línea de comandos también tiene una integración excelente con VS Code

  • httpyac también tiene buena compatibilidad con el soporte de .http en los IDE de JetBrains
    JetBrains también ofrece una herramienta gratuita de línea de comandos que genera reportes de pruebas jUnit a partir de archivos .http

• Me enteré de que Visual Studio 2022 también soporta algo parecido con archivos .http: https://learn.microsoft.com/en-us/aspnet/core/test/http-file...
  Hurl parece tener muchas más funciones

  • Los IDE de JetBrains también soportan esto, así que por ahora parece una especie de formato cercano a un estándar en comparación con otras opciones
  • Hurl es mucho más rápido
  • Llevo tiempo usando la extensión de VS Code en la que se basó esta función