เปิดตัว Hurl 4.0.0

 (hurl.dev)
2 คะแนน โดย GN⁺ 2023-07-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Hurl 4.0.0 คือเวอร์ชันใหม่ของเครื่องมือทดสอบ HTTP แบบ CLI ที่ทำงานบนพื้นฐานของ curl โดยปรับปรุงโฟลว์การรันคำขอ HTTP และการตรวจสอบคำตอบที่เขียนไว้ในไฟล์ข้อความธรรมดา
  • รายงาน HTML ถูกสร้างเป็น HTML ล้วน ที่ใช้เพียง inline CSS โดยไม่มี JavaScript พร้อมแสดงวอเตอร์ฟอลไทม์ไลน์ของแต่ละคำขอ/คำตอบ, บันทึกการรัน และข้อผิดพลาดแบบอินไลน์
  • --error-format long จะแสดง response header และ body ของเทสต์ที่ล้มเหลว ทำให้ตรวจสอบบริบทที่จำเป็นต่อการหาสาเหตุใน CI/CD debugging ได้โดยไม่ต้องรันซ้ำ
  • ฟิลเตอร์ใหม่ decode และ xpath ช่วยให้ถอดรหัส response byte ที่ charset ไม่ชัดเจนได้โดยตรง และทำการตรวจสอบ XPath กับบางส่วนของ HTML ได้
  • มีการเปลี่ยนบางส่วนในวิธีประเมิน JSONPath และรองรับ custom HTTP method ที่เป็นตัวพิมพ์ใหญ่ จึงสามารถทดลองเมธอดใหม่อย่าง QUERY ได้

ภาพรวม Hurl 4.0.0

  • Hurl เป็น เครื่องมือบรรทัดคำสั่ง ที่ทำงานบนพื้นฐานของ curl สำหรับรันคำขอ HTTP ที่นิยามไว้ในรูปแบบข้อความธรรมดาอย่างเรียบง่าย
  • ในไฟล์ Hurl สามารถเขียนคำขอ, สถานะ HTTP ที่คาดหวัง, และ การตรวจสอบ (assert) เช่น header, certificate, JSONPath ไว้ด้วยกันได้
  • Hurl 4.0.0 เปลี่ยนแปลงหลัก ๆ ในด้านรายงาน HTML, การแสดงข้อผิดพลาด, ฟิลเตอร์, พฤติกรรม JSONPath และการรองรับ custom HTTP method

รายงาน HTML และวอเตอร์ฟอลไทม์ไลน์

  • Hurl HTML report สร้างข้อมูล 3 ส่วนในแต่ละการรัน
    • วอเตอร์ฟอลไทม์ไลน์: แสดงคำขอ/คำตอบแต่ละรายการเป็นกราฟ และดูช่วงเวลาอย่าง DNS, TCP handshake, time to first byte ได้
    • บันทึกการรัน: รวม request/response header และข้อมูล certificate เป็นต้น
    • ไฟล์ซอร์สที่ทำ syntax highlighting: แสดงข้อผิดพลาดแบบอินไลน์
  • รายงานนี้สร้างจาก HTML ล้วน และ inline CSS โดยไม่มี JavaScript ทำให้นำไปผนวกกับสภาพแวดล้อม CI/CD เช่น GitLab CI/CD หรือ GitHub Actions ได้ง่าย
  • เวลาในการวัดที่ใช้ในวอเตอร์ฟอลไทม์ไลน์มาจาก libcurl และเปิดเผยผ่าน --json option ได้เช่นกัน
    • --json ให้ข้อมูลการรันแบบมีโครงสร้าง รวมถึงข้อผิดพลาด, assert, certificate, capture, cookie และ timing
    • สามารถใช้ผลลัพธ์ JSON นี้สร้างรายงานของตนเองได้

คอขวดด้านประสิทธิภาพของ assert ที่มองเห็นได้จากการทำ visualization

  • การทำ visualization ที่ละเอียดอาจเผยปัญหาด้านประสิทธิภาพที่ซ่อนอยู่
  • ในบางการรันพบว่าเกิด ช่วงห่างขนาดใหญ่ ระหว่างคำขอ และสาเหตุมาจากจำนวน assert ของ HTTP response ที่มีมากมาก
  • ณ Hurl 4.0.0 การคำนวณ assert ยังทำงานด้วยวิธีที่ค่อนข้างตรงไปตรงมา
    • assert แต่ละตัวของ response เดียวกันถูกประมวลผลแยกจากกัน
    • ทุก assert จะ parse ใหม่ตั้งแต่ต้นและคำนวณซ้ำอีกครั้ง
  • ทีม Hurl มั่นใจในความเร็วจากการใช้ libcurl ร่วมกับ Rust แต่กรณีนี้ทำให้เห็นว่าควรมีการ ปรับปรุงประสิทธิภาพของ assert ในรีลีสถัดไป

การแสดงข้อผิดพลาดแบบละเอียดสำหรับ CI/CD

  • เดิมการแสดงผลเมื่อเทสต์ล้มเหลวมักเน้นค่าที่คาดหวัง จึงอาจมีข้อมูลไม่พอสำหรับการวิเคราะห์
  • --error-format option ใหม่ช่วยให้เลือกคำอธิบายข้อผิดพลาดแบบยาวขึ้นได้
  • ในโหมด --error-format long จะบันทึก response header และ response body ลงในล็อกโดยอัตโนมัติ
  • ในตัวอย่าง เทสต์กำลังค้นหา header Control-Security-Policy แต่ response จริงมี Content-Security-Policy
    • เมื่อมี response header และ body อยู่ในล็อก จึงตรวจพบปัญหาประเภทพิมพ์ผิดได้ง่าย
  • ตัวเลือกนี้มีประโยชน์ใน สภาพแวดล้อม CI/CD ที่ต้องการบริบทสำหรับการดีบักเซสชันโดยไม่ต้องรันเทสต์ใหม่
  • เนื่องจากบันทึกถึง response body ด้วย ล็อกจึงอาจยาวมาก

ฟิลเตอร์ใหม่: decode และ xpath

  • text assert ของ Hurl จะถอดรหัส response body byte โดยอัตโนมัติ โดยใช้คำใบ้ charset จาก response header Content-Type
  • บางครั้ง Content-Type ไม่มีข้อมูล encoding หรือมีการระบุ charset ไว้ในแท็ก <meta> ภายในเอกสาร HTML
  • decode filter ใหม่ช่วยให้ถอดรหัส byte เป็นข้อความอย่างชัดเจนก่อนตรวจสอบได้
    • ตัวอย่างใช้ bytes decode "gb2312" เพื่อถอดรหัส body ที่เข้ารหัสด้วย GB2312
  • xpath filter ใหม่ช่วยให้ประเมิน XPath expression กับบางส่วนของ response ได้
    • ตัวอย่างใช้ xpath "string(//body)" เพื่อตรวจสอบข้อความใน body ของ HTML

การเปลี่ยนวิธีประเมิน JSONPath

  • Hurl 4.0.0 ปรับเปลี่ยนบางส่วนในการประเมินคิวรี JSONPath
  • JSONPath ไม่มีสเปกทางการที่เหมาะสม และ Hurl พยายามยึดตามเอกสาร goessner.net ที่ถูกใช้งานเสมือนเป็นมาตรฐานให้มากที่สุด
  • แต่ละ implementation มี edge case ที่ต่างกัน
    • JSONPath แบบมาตรฐานจะคืนค่าเป็น collection เสมอ แต่ในหลายกรณีอาจไม่ได้มีความหมายมากนักและทำให้การทดสอบยาก
    • บาง implementation แยก node value ของ definite path ออกจาก collection ของ indefinite path
  • ใน Hurl 4.0.0 selector ที่คืนค่าเป็น value มีเพียง 2 แบบ
    • selector แบบ array index: $.store.book[2]
    • selector แบบ object key: $.store.bicycle.color, $.store.bicycle['color']
  • selector ที่ใช้ filter หรือ selector อย่าง $[*].id จะคืนค่าเป็น collection
    • หากต้องการดึงค่าจาก collection สามารถใช้ nth filter ได้

Custom HTTP method

  • Hurl 4.0.0 รองรับ custom HTTP method ได้ตามต้องการ
  • เมธอดต้องเขียนเป็นตัวพิมพ์ใหญ่
  • ตัวอย่างเช่น สามารถทดลองเมธอดใหม่ QUERY ที่กำลังจะเข้ามาได้ทันที

รีลีสโน้ตและคำเชิญให้มีส่วนร่วม

  • การปรับปรุงและการแก้บั๊กอื่น ๆ ดูได้จาก release note
  • โปรเจ็กต์นี้เชิญชวนให้ช่วยกด GitHub star, แชร์บน Twitter, ส่งคำขอปรับปรุง และแบ่งปันกรณีการใช้งาน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-01
ความคิดเห็นจาก Hacker News

  • ชอบที่คำแนะนำของ Hurl เริ่มต้นด้วยคำว่า “เครื่องมือบรรทัดคำสั่งที่ใช้ curl เป็นฐาน สำหรับรัน HTTP request ที่นิยามไว้ในรูปแบบ plain text แบบง่าย”
    เพิ่งเคยเห็น Hurl ครั้งแรก แต่แค่ คำอธิบายสั้น ๆ กับตัวอย่างโค้ด ด้านบนก็ทำให้อยากติดตั้งมาลองใช้ทันที ดูเป็นรีลีสที่ยอดเยี่ยม

    • ในฐานะผู้ดูแลหลักของ Hurl ผมอ่าน Hacker News มานาน และคอยจด คำแนะนำเรื่องการนำเสนอ อย่าง “โชว์ตัวอย่างภาษาให้เร็วที่สุด”, “อธิบายแนวคิดให้กระชับทุกครั้ง” เอาไว้ แล้วก็พยายามนำไปใช้จริงบน hurl.dev
    • โพสต์เปิดตัวและ README จำนวนมากเริ่มจาก requirement การติดตั้งหรือ “เราแก้ X, Y, Z” ทั้งที่ยังไม่บอกเลยว่า เครื่องมือนี้ทำอะไร วิธีนี้แหละถูกต้องแล้ว
    • ก็จริง แต่ส่วนใหญ่สิ่งนั้นควรอยู่ในชื่อบทความด้วย
      เช่นชื่อแบบ Hurl: Run HTTP requests in a simple plain-text format น่าจะดีกว่า

  • อยากให้สิ่งนี้กลายเป็น มาตรฐานอุตสาหกรรมของการทดสอบ API
    เบื่อทั้งการดูภาพหน้าจอ Postman ที่ QA ส่งมา และการต้องรอให้ QA กด Send หลังแก้ไขเสร็จ ฝั่ง QA เองก็คงเบื่อที่ต้องรอนักพัฒนาเหมือนกัน
    Hurl เป็นสิ่งที่ทั้งนักพัฒนาและ QA อ่านและเขียนได้ รองรับ automation และการเชื่อมกับ CI สื่อสารพฤติกรรมที่คาดหวังได้ง่าย และใส่ไปพร้อมกับ PR เพื่อเป็นจุดเริ่มต้นให้ QA ได้ด้วย ดังนั้นในที่ที่ใช้ได้ก็ดูแทบไม่มีเหตุผลที่จะไม่ใช้

    • ผมใช้ Hurl ทั้งกับ การทดสอบ API แบบ manual และใน CI สำหรับบริการหนึ่งอยู่ ค่อนข้างดีทีเดียว
      คุณสามารถใส่ลำดับการแลกเปลี่ยน HTTP ของแต่ละ workflow ไว้ในไฟล์ hurl ไฟล์เดียว แล้วมันก็กลายเป็น test suite ที่เข้า Git ได้ตรง ๆ
    • ถ้าทีมใช้ VSCode ก็อาจลอง vscode-restclient ได้เช่นกัน: https://github.com/Huachao/vscode-restclient
      แต่ Hurl ก็น่าสนใจมาก และผมเห็นด้วยว่าความที่ไม่ผูกกับ editor ใด editor หนึ่งเป็นทางออกที่ดีกว่าสำหรับปัญหานี้
    • สงสัยว่าเคยลอง https://k6.io/ ไหม
      มันให้คุณเขียนการทดสอบโหลด/ประสิทธิภาพด้วย JS แล้ว commit เข้า repository ทำ automation บน CI ได้ง่าย ส่ง metrics ไปยัง backend ได้หลายแบบ ใช้กับโปรโตคอลอื่นนอกเหนือจาก HTTP ได้ และมี command-line interface ที่ทันสมัยพร้อมฟีเจอร์มากมาย
      ยังมีตัวแปลง Postman-to-k6 ด้วย: https://github.com/apideck-libraries/postman-to-k6
      ปรัชญาของ k6 คือให้นักพัฒนาเขียนการทดสอบลักษณะนี้เองเหมือน unit/integration test เพื่อตัดวงจร QA-นักพัฒนาแบบเดิม Hurl ก็ดูดี แต่ฟีเจอร์จำกัดกว่าเครื่องมือทดสอบประสิทธิภาพที่มีอยู่ และส่วนตัวผมชอบ เขียนการทดสอบด้วยภาษาโปรแกรม มากกว่ารูปแบบข้อความเฉพาะทาง
    • ส่วนตัวผมชอบแนวทางที่นิยามด้วย OpenAPI แล้วใช้ Dredd ตรวจสอบสเปก
      ต่อให้ใช้เครื่องมือที่สร้างสเปกจากซอร์สโค้ด ความผิดพลาดของผู้ใช้ในการกำหนด endpoint metadata ก็ยังเกิดขึ้นได้ และ Dredd จะช่วยจับจุดนั้น

  • นี่เกือบเป็นตัวอย่างที่ดีที่สุดของโปรแกรม Unix สมัยใหม่เท่าที่เคยเห็น
    รับจาก standard input ส่งออกทาง standard output ไม่ยัด Unicode emoji ไปทั่ว terminal และมี man page ที่ทำไว้ค่อนข้างดี
    ยังชอบด้วยที่นามสกุลไฟล์ hurl มี 4 ตัวอักษร ไม่ใช่ 3 ตัว เหมือนในที่สุดเราก็เลิกกังวลเรื่องความเข้ากันได้กับ MS-DOS เสียที
    ดูเป็นเครื่องมือที่น่าลองใช้อย่างจริงจัง

    • ไม่เคยรู้มาก่อนว่า emoji ใน terminal น่ารำคาญแค่ไหน แต่พอเห็นว่าตัวนี้ไม่มี ก็รู้สึกชอบขึ้นมาทันที
    • ไม่ใช่แค่ MS-DOS แต่ยังหลุดพ้นจากข้อกังวลเรื่องความเข้ากันได้กับ VMS ด้วย

  • สำหรับเครื่องมือจัดการ HTTP บนบรรทัดคำสั่ง ผมชอบ Httpie หรือไม่ก็ XH ซึ่งเป็นเวอร์ชันเขียนใหม่ด้วย Rust ที่เร็วกว่า
    มันให้ไวยากรณ์บนบรรทัดคำสั่งที่ใกล้กับ HTTP มากกว่า curl มาก และไม่ต้องเรียนรู้ option จำนวนมาก
    ถ้าคุณชินกับ curl อยู่แล้วอาจไม่ได้มีประโยชน์มาก แต่สำหรับการใช้งานเบา ๆ มันเข้าใจง่ายกว่ามาก
    https://httpie.io/
    https://github.com/ducaale/xh

  • ที่ Adaptive เราใช้ hurl.dev อย่างกว้างขวางกับงานทดสอบอัตโนมัติ: https://adaptive.live
    เราทดสอบ product flow ภายในทั้งหมดด้วย Hurl และมันเป็นหนึ่งในการตัดสินใจที่ดีที่สุดที่เราเอาเข้ามาใช้ในองค์กรในแง่ของการทำให้ผลิตภัณฑ์เสถียร
    ก่อน deploy ทุกครั้ง เราจะรัน automated test ที่อิง Hurl หลายชุดเพื่อตรวจสอบ onboarding, signup, flow หลักต่าง ๆ และเพราะมันทำงานแบบ containerized จึงรันแบบขนานได้ด้วย
    เรายังสร้างเครื่องมือภายในรอบ ๆ hurl.dev อยู่ และชอบที่มันเรียนรู้ได้ง่ายจนแม้แต่นักวิเคราะห์หรือผู้ใช้ฝั่งธุรกิจก็สร้างการทดสอบได้

    • สงสัยว่าทำไมถึงเลือกใช้เครื่องมือแบบ standalone
      ในบริบทของการทดสอบ วิธีแบบ อิงเบราว์เซอร์ อย่าง Selenium ดูทรงพลังและใช้งานได้กว้างกว่ามาก
    • สงสัยว่ารองรับ OAuth flow แบบ built-in ไหม หรือจำเป็นต้องใช้ token ที่ hardcode ไว้
      ผมดูเอกสารแล้วแต่ยังหาเรื่องนี้ไม่เจอ

  • ผมติดตาม hurl มาสักพักแล้ว จุดที่ต่างจากเครื่องมืออื่นคือมี DSL ของตัวเอง สำหรับการทดสอบ
    มันไม่ได้แค่ส่ง HTTP request แต่ยังตรวจสอบ response และ capture ข้อมูลได้ด้วย
    แต่ถ้าผู้ดูแลกำลังอ่านอยู่ ผมอยากให้มันเปิดทางให้ส่งการตรวจสอบออกไปทำในสคริปต์ภายนอกได้
    เช่น ถ้าจะตรวจว่าทุก property ของ collection ของรายการมีค่าเหมือนกัน ตอนนี้ยังทำได้ยากถ้าไม่ใช้ selector แบบ nth และก็น่าจะต้องมีอะไรอย่าง nth = * ด้วย
    การพยายามทำทุก use case ให้ครอบคลุมด้วย DSL เป็นงานที่ใหญ่เกินไป ดังนั้นถ้าส่งผลลัพธ์ของ jsonpath ไปให้ jq แล้วให้ test ผ่านเมื่อได้ค่า true ได้ ก็น่าจะดี

    • DSL สุดท้ายแล้วก็มักค่อย ๆ ขยายจนกลายเป็นภาษาทั่วไปที่ทัวริงสมบูรณ์ ดังนั้นการเรียกสคริปต์ภายนอกจึงดูสมเหตุสมผล
      แต่ถ้าทำแบบนั้น ไฟล์ก็จะไม่เป็น self-contained เท่าเดิม และอาจก่อให้เกิดปัญหาซับซ้อนพอสมควร

  • Hurl ดูเติบโตเร็วดี
    เวลาเทสต์ endpoint มักต้องมีการยืนยันตัวตนเสมอ เลยสงสัยว่ามีวิธีเขียน auth ไว้ในไฟล์หนึ่ง แล้วดึงมาใช้ตอนต้นของอีกไฟล์ที่ต้องใช้ token หรือไม่

    • ดูเหมือน Hurl จะยังไม่มีฟีเจอร์อย่าง include หรือ macro
      และจริง ๆ ก็ไม่แน่ใจว่าวิธีแบบนั้นเป็นแนวทางที่ดีที่สุดในการเก็บและใช้ค่าลับหรือเปล่า
      ตามเอกสาร คุณสามารถส่งตัวแปรเข้าไฟล์ hurl ผ่าน command-line argument และ environment variable ได้: https://hurl.dev/docs/templates.html

  • สำหรับงานแบบนี้ผมก็ชอบ httpyac มากเหมือนกัน: https://httpyac.github.io
    มันมีความสามารถด้าน JS scripting เลยค่อนข้างคล้ายกัน และไม่ใช่แค่ command-line interface เท่านั้น แต่ยัง integrate กับ VS Code ได้ดีมาก

    • httpyac ยังเข้ากันได้ดีกับการรองรับ .http ของ JetBrains IDE ด้วย
      JetBrains ยังมีเครื่องมือบรรทัดคำสั่งฟรีที่สร้างรายงานการทดสอบแบบ jUnit จากไฟล์ .http ได้ด้วย

  • เพิ่งรู้ว่า Visual Studio 2022 ก็รองรับความสามารถคล้ายกันผ่านไฟล์ .http: https://learn.microsoft.com/en-us/aspnet/core/test/http-file...
    แต่ Hurl ดูจะมีฟีเจอร์มากกว่ามาก

    • JetBrains IDE ก็รองรับสิ่งนี้เช่นกัน ดังนั้นตอนนี้มันเลยดูเหมือนเป็นรูปแบบที่ ใกล้เคียงมาตรฐาน มากกว่าวิธีอื่น
    • Hurl เร็วกว่ามาก
    • ผมใช้ VS Code extension ที่เป็นพื้นฐานของฟีเจอร์นี้มาสักพักแล้ว