Phát hành Hurl 4.0.0

 (hurl.dev)
2 điểm bởi GN⁺ 2023-07-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hurl 4.0.0 là phiên bản mới của công cụ kiểm thử HTTP CLI dựa trên curl, cải thiện luồng thực thi các HTTP request và kiểm chứng response được viết trong tệp văn bản thuần
  • Báo cáo HTML được tạo dưới dạng HTML thuần chỉ dùng CSS inline, không có JavaScript, đồng thời hiển thị waterfall timeline theo từng request/response, log thực thi và lỗi inline
  • --error-format long in ra header và body của response trong các bài test thất bại, giúp xem ngữ cảnh cần thiết để xác định nguyên nhân trong debug CI/CD mà không phải chạy lại
  • Với các filter mới decode và xpath, có thể trực tiếp decode các byte response khi charset không rõ ràng và thực hiện kiểm chứng XPath trên một phần HTML
  • Một số cách đánh giá JSONPath đã thay đổi, đồng thời hỗ trợ custom HTTP method thỏa điều kiện viết hoa, cho phép thử nghiệm cả các method mới như QUERY

Tổng quan Hurl 4.0.0

  • Hurl là công cụ dòng lệnh dựa trên curl, dùng để thực thi các HTTP request được định nghĩa bằng một định dạng văn bản thuần đơn giản
  • Trong tệp Hurl, có thể viết kèm request, trạng thái HTTP kỳ vọng và các kiểm chứng (assert) như header, chứng chỉ, JSONPath
  • Hurl 4.0.0 thay đổi chủ yếu ở báo cáo HTML, output lỗi, filter, hành vi JSONPath và hỗ trợ custom HTTP method

Báo cáo HTML và waterfall timeline

  • Hurl HTML report tạo ra ba loại thông tin cho mỗi lần chạy
    • Waterfall timeline: hiển thị từng request/response bằng đồ thị và cho phép xem timing của response như DNS, TCP handshake, time to first byte
    • Log thực thi: bao gồm header request/response và thông tin chứng chỉ
    • Tệp nguồn được tô sáng cú pháp: hiển thị lỗi inline
  • Báo cáo được cấu thành từ HTML thuần và CSS inline, không có JavaScript, nên dễ tích hợp vào các môi trường CI/CD như GitLab CI/CD hoặc GitHub Actions
  • Timing dùng trong waterfall timeline do libcurl cung cấp và cũng được expose qua tùy chọn --json
    • --json cung cấp thông tin thực thi có cấu trúc, bao gồm lỗi, assert, chứng chỉ, capture, cookie và timing
    • Có thể dùng output JSON này để tạo báo cáo riêng

Nút thắt hiệu năng assert lộ ra nhờ trực quan hóa

  • Trực quan hóa phong phú có thể làm lộ ra các vấn đề hiệu năng bị che giấu
  • Trong một số lần chạy, xuất hiện khoảng cách lớn giữa các request, nguyên nhân là số lượng assert trên HTTP response rất lớn
  • Tính đến Hurl 4.0.0, việc tính toán assert hoạt động theo cách đơn giản
    • Mỗi assert của cùng một response được xử lý độc lập
    • Mỗi assert đều parse lại từ đầu và tính toán lại
  • Nhóm Hurl từng tự tin về tốc độ nhờ kết hợp libcurl và Rust, nhưng từ trường hợp này họ nhận thấy cần cải thiện hiệu năng assert trong bản phát hành tiếp theo

Output lỗi chi tiết cho CI/CD

  • Output khi test thất bại trước đây tập trung vào giá trị kỳ vọng nên có thể thiếu thông tin cần thiết để phân tích
  • Với tùy chọn --error-format mới, có thể chọn mô tả lỗi dài hơn
  • Ở chế độ --error-format long, header response và body response sẽ tự động được ghi vào log
  • Trong ví dụ, test đang tìm header Control-Security-Policy, nhưng response thực tế có Content-Security-Policy
    • Vì header và body response được đưa vào log, có thể dễ dàng nhận ra vấn đề dạng lỗi chính tả
  • Tùy chọn này hữu ích trong môi trường CI/CD khi muốn lấy ngữ cảnh cần thiết để debug phiên mà không chạy lại test
  • Vì ghi cả body response, log có thể trở nên rất dài

Filter mới: decode và xpath

  • Assert văn bản của Hurl tự động decode byte của body response, khi đó dùng gợi ý charset trong header response Content-Type
  • Có trường hợp Content-Type không có encoding, hoặc charset nằm trong thẻ <meta> bên trong tài liệu HTML
  • Filter decode mới cho phép decode byte thành văn bản một cách tường minh để kiểm chứng
    • Ví dụ decode body được mã hóa GB2312 bằng bytes decode "gb2312"
  • Filter xpath mới cho phép đánh giá biểu thức XPath trên một phần response
    • Ví dụ kiểm chứng văn bản body của HTML bằng xpath "string(//body)"

Thay đổi cách đánh giá JSONPath

  • Hurl 4.0.0 thay đổi một phần cách đánh giá truy vấn JSONPath
  • JSONPath không có đặc tả chính thức phù hợp, và Hurl cố gắng bám sát tối đa tài liệu goessner.net, vốn được dùng như một chuẩn trên thực tế
  • Có các edge case khác nhau giữa các implementation
    • JSONPath chuẩn luôn trả về collection, nhưng trong đa số trường hợp điều này không có nhiều ý nghĩa và có thể khó kiểm thử
    • Một số implementation phân biệt giữa giá trị node của definite path và collection của indefinite path
  • Trong Hurl 4.0.0, chỉ có hai loại selector trả về giá trị
    • Selector chỉ mục mảng: $.store.book[2]
    • Selector khóa object: $.store.bicycle.color, $.store.bicycle['color']
  • Các selector dùng filter hoặc selector như $[*].id trả về collection
    • Để lấy giá trị từ collection, có thể dùng filter nth

Custom HTTP method

  • Hurl 4.0.0 hỗ trợ custom HTTP method tùy ý
  • Method phải được viết bằng chữ hoa
  • Ví dụ có thể thử nghiệm ngay method QUERY sắp xuất hiện

Release note và lời mời tham gia

  • Các cải tiến và bản sửa lỗi khác có thể xem trong release note
  • Dự án kêu gọi GitHub star, chia sẻ trên Twitter, gửi yêu cầu cải tiến và chia sẻ use case

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-07-01
Ý kiến trên Hacker News

  • Tôi thích cách phần giới thiệu Hurl bắt đầu bằng câu “một công cụ dòng lệnh dựa trên curl, thực thi các yêu cầu HTTP được định nghĩa bằng một định dạng văn bản thuần đơn giản”
    Đây là lần đầu tôi thấy Hurl, nhưng chỉ với phần giới thiệu ngắn và ví dụ code ở ngay đầu, tôi đã muốn cài đặt và dùng thử ngay; trông đây là một bản phát hành rất tốt

    • Với tư cách maintainer của Hurl, tôi đã đọc Hacker News từ lâu và ghi lại mọi lời khuyên khi công bố sản phẩm như “hãy cho xem mẫu ngôn ngữ càng sớm càng tốt”, “mỗi lần đều giải thích khái niệm thật súc tích”, rồi cố gắng thực sự phản ánh chúng trên hurl.dev
    • Có quá nhiều bài công bố và README bắt đầu bằng yêu cầu cài đặt hoặc “đã sửa X, Y, Z” mà lại không nói rõ công cụ này làm gì; cách làm này mới đúng
    • Nói đúng, nhưng phần lớn những điều đó đáng lẽ nên nằm trong tiêu đề bài viết
      Ví dụ một tiêu đề như Hurl: Run HTTP requests in a simple plain-text format sẽ hay hơn

  • Tôi mong công cụ này trở thành tiêu chuẩn ngành cho kiểm thử API
    Tôi đã mệt với việc xem ảnh chụp màn hình Postman do QA gửi, cũng như chờ QA bấm Send sau khi sửa xong; chắc QA cũng mệt vì phải chờ lập trình viên
    Hurl có thể được cả lập trình viên lẫn QA đọc và viết, có thể tự động hóa và tích hợp CI, dễ truyền đạt hành vi kỳ vọng, và có thể đưa kèm vào PR để làm điểm xuất phát cho QA, nên ở những nơi dùng được thì có vẻ không có lý do gì để không dùng

    • Ở một dịch vụ, chúng tôi đang dùng Hurl cho kiểm thử API thủ công và CI, và nó khá tốt
      Có thể đưa luồng trao đổi HTTP theo từng workflow vào một file hurl, và nó trở thành một bộ test đưa thẳng vào Git
    • Nếu nhóm dùng VSCode thì cũng có thể thử vscode-restclient: https://github.com/Huachao/vscode-restclient
      Tuy vậy Hurl cũng rất thú vị, và tôi đồng ý rằng việc không phụ thuộc vào editor là lời giải tốt hơn cho vấn đề này
    • Không rõ bạn đã thử https://k6.io/ chưa
      Công cụ này cho phép viết kiểm thử tải/hiệu năng bằng JS rồi commit vào repository, tự động hóa dễ dàng trong CI, gửi chỉ số tới nhiều backend, dùng cả các protocol ngoài HTTP, cung cấp giao diện dòng lệnh hiện đại cùng nhiều tính năng
      Cũng có bộ chuyển đổi Postman-to-k6: https://github.com/apideck-libraries/postman-to-k6
      Triết lý của k6 là để lập trình viên viết các test này giống như unit/integration test, từ đó phá vỡ vòng lặp QA–dev kiểu cũ; Hurl cũng có vẻ tốt, nhưng tính năng hạn chế hơn so với các công cụ kiểm thử hiệu năng hiện có, và cá nhân tôi thích viết test bằng ngôn ngữ lập trình hơn là bằng một định dạng văn bản riêng
    • Cá nhân tôi thích cách tiếp cận định nghĩa bằng OpenAPI rồi dùng Dredd để kiểm chứng đặc tả
      Ngay cả khi dùng công cụ tạo đặc tả từ source code, người dùng vẫn có thể định nghĩa sai metadata của endpoint, và Dredd sẽ bắt được lỗi đó

  • Đây gần như là ví dụ tốt nhất về một chương trình Unix hiện đại mà tôi từng thấy
    Nhận chuẩn vào, xuất ra chuẩn ra, không lạm dụng emoji Unicode khắp terminal, và man page cũng được chuẩn bị khá đầy đủ
    Tôi cũng thích việc phần mở rộng file hurl có bốn chữ chứ không phải ba; có vẻ cuối cùng cũng thoát khỏi nỗi lo tương thích MS-DOS
    Trông đây là một công cụ đáng để nghiêm túc dùng thử

    • Tôi không nhận ra emoji trong terminal từng gây khó chịu đến mức nào, nhưng khi thấy nói công cụ này không có chúng thì tự nhiên lại thấy mừng
    • Không chỉ MS-DOS, cũng coi như thoát khỏi nỗi lo tương thích VMS

  • Trong các công cụ xử lý HTTP dòng lệnh, tôi thích Httpie nhất, hoặc XH, bản viết lại bằng Rust nhanh hơn
    Có thể gửi request từ dòng lệnh với cú pháp gần với HTTP hơn curl rất nhiều, và không cần học quá nhiều option
    Nếu đã quen với curl thì có thể không hữu ích lắm, nhưng để dùng nhẹ nhàng thì trực quan hơn nhiều
    https://httpie.io/
    https://github.com/ducaale/xh

  • Ở Adaptive, chúng tôi đang dùng rộng rãi hurl.dev cho tự động hóa kiểm thử: https://adaptive.live
    Chúng tôi kiểm thử toàn bộ luồng sản phẩm nội bộ bằng Hurl, và đó là một trong những lựa chọn tốt nhất mà tổ chức đã áp dụng xét về mặt ổn định sản phẩm
    Trước mỗi lần deploy, chúng tôi chạy nhiều test tự động dựa trên Hurl để xác minh onboarding, đăng ký, các luồng cốt lõi, v.v.; chúng được container hóa và cũng có thể chạy song song
    Chúng tôi cũng đang xây dựng công cụ nội bộ quanh hurl.dev, và điểm hay là nó dễ học nên cả analyst hoặc người dùng nghiệp vụ cũng có thể tạo test

    • Tôi tò mò vì sao lại dùng một công cụ độc lập
      Trong bối cảnh kiểm thử, một cách tiếp cận dựa trên trình duyệt như Selenium có vẻ mạnh hơn và hữu ích hơn về tổng thể
    • Tôi thắc mắc liệu công cụ này có hỗ trợ sẵn luồng OAuth không, hay cần token hard-code
      Tôi đã xem tài liệu nhưng không tìm thấy nội dung liên quan

  • Tôi đã theo dõi hurl một thời gian, và điểm khác biệt so với các công cụ khác là nó có DSL riêng cho kiểm thử
    Nó không chỉ gửi request HTTP mà còn có thể xác minh response và capture dữ liệu
    Tuy nhiên, nếu maintainer đang đọc, tôi mong có thể chuyển phần xác minh sang script bên ngoài
    Ví dụ, để kiểm chứng mọi thuộc tính trong một collection đều có cùng giá trị, hiện vẫn khó làm nếu không dùng selector nth, và cũng cần một kiểu như nth = *
    Việc cung cấp mọi use case bằng DSL là một khối lượng công việc quá lớn, nên sẽ tốt nếu có thể chuyển kết quả jsonpath sang jq, rồi nếu trả về true thì cho test pass

    • DSL rồi cuối cùng cũng sẽ dần phình thành một ngôn ngữ đa dụng Turing-complete, nên việc gọi script bên ngoài có vẻ hợp lý
      Tuy nhiên, làm vậy có thể khiến file kém độc lập hơn và phát sinh những vấn đề khá phức tạp

  • Hurl đang phát triển nhanh, trông rất tốt
    Khi test endpoint thì luôn cần xác thực; tôi thắc mắc có cách nào viết phần xác thực trong một file rồi import ở đầu các file khác cần token không

    • Có vẻ Hurl không có tính năng như include hay macro
      Dù sao cũng chưa chắc cách đó là tốt nhất để lưu và dùng secret
      Theo tài liệu, có thể truyền biến vào file hurl thông qua tham số dòng lệnh và biến môi trường: https://hurl.dev/docs/templates.html

  • Với mục đích này, tôi cũng khá thích httpyac: https://httpyac.github.io
    Nó có tính năng scripting bằng JS nên khá tương tự, và không chỉ giao diện dòng lệnh mà tích hợp VS Code cũng rất tốt

    • httpyac cũng tương thích tốt với hỗ trợ .http của JetBrains IDE
      JetBrains cũng cung cấp một công cụ dòng lệnh miễn phí để tạo báo cáo test jUnit từ file .http

  • Tôi mới biết Visual Studio 2022 cũng hỗ trợ tính năng tương tự bằng file .http: https://learn.microsoft.com/en-us/aspnet/core/test/http-file...
    Hurl có vẻ có nhiều tính năng hơn hẳn

    • JetBrains IDE cũng hỗ trợ điều này, nên hiện tại trông nó phần nào giống một định dạng gần với tiêu chuẩn hơn các cách khác
    • Hurl nhanh hơn nhiều
    • Tôi đã dùng extension VS Code làm nền tảng cho tính năng này được một thời gian