Hoppscotch CLI เป็นเครื่องมือโอเพ่นซอร์สฟรีที่ใช้ในการรันคอลเลกชัน API จากเทอร์มินัล หากคุณใช้ Hoppscotch บนเว็บหรือเดสก์ท็อปอยู่แล้ว hopp test ช่วยให้คุณสามารถผลักดันคำขอเหล่านั้นเข้าสู่ CI pipeline ได้โดยไม่ต้องเสียค่าใช้จ่ายใดๆ นี่คือจุดแข็งที่แท้จริง และบทความนี้จะไม่แกล้งทำเป็นอย่างอื่น
แต่ Hoppscotch CLI ก็ถูกออกแบบมาให้มีขอบเขตจำกัดโดยเจตนา มันรันคอลเลกชันและรายงานผลลัพธ์ ไม่ได้ออกแบบ API, สร้าง API จำลอง (mock), จัดทำเอกสาร, หรือจัดการเป็นโค้ด ดังนั้นหลายทีมจึงมาถึงจุดที่พวกเขาต้องการเครื่องมือเดียวที่สามารถทำอะไรได้มากกว่าแค่การรันไฟล์ JSON หรือพวกเขาพบปัญหา เช่น ข้อกำหนด Node v22 และเริ่มมองหาทางเลือกอื่น
Hoppscotch CLI ทำอะไรได้บ้าง
Hoppscotch CLI มาในรูปแบบแพ็คเกจ npm @hoppscotch/cli คุณสามารถติดตั้งแบบ global ได้ดังนี้:
npm i -g @hoppscotch/cli
สิ่งหนึ่งที่ควรรู้ล่วงหน้าคือ มันต้องการ Node.js v22 หรือใหม่กว่า หากคุณยังติดอยู่กับ Node 20 คุณจะต้องใช้ CLI v0.26.0 ซึ่งอาจทำให้เกิดความยุ่งยากใน CI image ที่ใช้ร่วมกันซึ่งงานอื่นๆ กำหนด Node เวอร์ชันเก่ากว่า
คำสั่งหลักคือ hopp test คุณชี้ไปที่ไฟล์คอลเลกชัน (หรือ ID คอลเลกชันบนคลาวด์) แล้วมันจะรันทุกคำขอตามลำดับ:
hopp test ./collection.json -e ./environment.json -d 500
สำหรับอินสแตนซ์บนคลาวด์หรือที่โฮสต์เอง คุณจะต้องส่ง ID พร้อมข้อมูลรับรอง:
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
มันจะรันสคริปต์ก่อนคำขอและสคริปต์ทดสอบ (ชุด pw.test(), กรณี pw.expect()) ตรวจสอบการตอบกลับ และจะออกจากการทำงานโดยมีค่าที่ไม่ใช่ศูนย์หากมีการยืนยันใดๆ ล้มเหลว นอกจากนี้ยังรองรับ --reporter-junit <path> สำหรับ JUnit XML รวมถึง --iteration-count และ --iteration-data <csv> สำหรับการรันแบบ data-driven นี่คือ runner ฟรีที่มีความสามารถอย่างแท้จริง
ทำไมทีมถึงมองหาทางเลือกอื่นแทน hopp test
เหตุผลที่ผู้คนมองหาเครื่องมืออื่นมาแทนที่ Hoppscotch CLI มักจะเป็นเรื่องของการใช้งานจริง ไม่ใช่เรื่องของแนวคิด:
- เป็นเพียงแค่ collection runner ไม่มีอะไรมากไปกว่านั้น การออกแบบ, การจำลอง (mocking), และเอกสารอยู่ที่อื่น คุณต้องเชื่อมโยงเครื่องมือหลายอย่างเข้าด้วยกัน
- คุณต้องส่งออกไฟล์ JSON ก่อน ข้อมูลจำเพาะและสภาพแวดล้อมมาในรูปแบบไฟล์คอลเลกชัน/สภาพแวดล้อมที่ส่งออก (หรือ cloud ID) ไม่มีตัวตรวจสอบความถูกต้องของข้อมูลจำเพาะ (spec linting) หรือเลเยอร์การออกแบบใน CLI เอง
- ข้อกำหนด Node v22 ซึ่งใหม่กว่าค่าเริ่มต้นของ build images จำนวนมาก หมายถึงการจัดการเวอร์ชันที่ซับซ้อนขึ้น
- ไม่มีเวิร์กโฟลว์ "spec-as-code" คุณไม่สามารถจัดการ endpoints, schemas, หรือ branches จาก CLI ได้ CLI เป็นเพียงส่วนหนึ่งที่ต่อยอดจากที่ที่คุณกำหนด API ไว้
ไม่มีสิ่งใดที่ทำให้ Hoppscotch ไม่ดี มันเป็นเครื่องมือที่มุ่งเน้น หากคุณต้องการความครอบคลุมที่กว้างขึ้น นี่คือทางเลือกที่คุ้มค่ากับเวลาของคุณ
1. Apidog CLI (ทางเลือกที่ดีที่สุดแบบ All-in-one)
Apidog เป็นแพลตฟอร์ม API แบบ all-in-one ที่ครอบคลุมการออกแบบ, การดีบัก, การสร้าง API จำลอง (mocking), การจัดทำเอกสาร, และการทดสอบ Apidog CLI นำการทดสอบและการจัดการทรัพยากรมาสู่เทอร์มินัลและ CI/CD ซึ่งเป็นสิ่งที่ทำให้มันเป็นทางเลือกที่แข็งแกร่งแทนการใช้ collection runner แบบเดี่ยว
ด้วย apidog run คุณสามารถรันสถานการณ์ทดสอบและคอลเลกชันจากบรรทัดคำสั่งได้ มันรองรับการทดสอบแบบ data-driven ผ่าน -d (ชุดข้อมูล CSV หรือ JSON), สภาพแวดล้อมผ่าน -e, ตัวรายงานผลในรูปแบบ CLI, HTML, และ JSON, และรายงานผลการทดสอบบนคลาวด์ด้วย --upload-report นอกเหนือจากการรันการทดสอบแล้ว CLI ยังสามารถนำเข้า OpenAPI และจัดการทรัพยากร API, endpoints, schemas, environments, branches, และ merge requests ได้ในรูปแบบโค้ด ดังนั้นการกำหนด API และการทดสอบของคุณจึงอยู่ในระบบเดียวกัน แทนที่จะต้องส่งออกไปมา
เพื่อความแม่นยำเกี่ยวกับขอบเขต: Apidog ตรวจสอบความถูกต้องของข้อมูลจำเพาะเมื่อนำเข้า แต่มันไม่มี OpenAPI linter แบบเดี่ยวหรือคำสั่ง split/join/bundle หากเป้าหมายของคุณคือการตรวจสอบความถูกต้องของข้อมูลจำเพาะ (spec linting) ใน CI อย่างแท้จริง inso (ด้านล่าง) จะเหมาะสมกว่า จุดเด่นของ Apidog คือการรวมเข้าด้วยกัน คุณออกแบบ, สร้าง API จำลอง (mock), จัดทำเอกสาร, และทดสอบในที่เดียว จากนั้นขับเคลื่อนเลเยอร์การทดสอบและทรัพยากรจาก CLI
ข้อดี:
- แพลตฟอร์มเดียวสำหรับการออกแบบ, การจำลอง (mock), เอกสาร, และการทดสอบ แทนที่จะเป็นชุดเครื่องมือ
- การรันแบบ Data-driven ด้วยชุดข้อมูล CSV/JSON
- ตัวรายงานผลในรูปแบบ CLI, HTML, และ JSON รวมถึงรายงานบนคลาวด์ที่สามารถอัปโหลดได้
- Resource-as-code: จัดการ endpoints, schemas, branches, และ merge requests จาก CLI
- นำเข้า OpenAPI โดยตรง
ข้อเสีย:
- ไม่มีคำสั่ง spec-linter แบบเดี่ยว (ใช้ inso หรือ Redocly สำหรับการตรวจสอบแบบ Spectral-style)
- แพลตฟอร์มเต็มรูปแบบอาจมากเกินความจำเป็นหากคุณรันเพียงแค่คอลเลกชันเดียวเท่านั้น
หากคุณกำลังเปรียบเทียบทั้งสองอย่างโดยตรง โปรดดู Apidog CLI vs Hoppscotch CLI และคำแนะนำการใช้งานจริงในการ migrate Hoppscotch CLI to Apidog CLI คู่มือฉบับสมบูรณ์ของ Apidog CLI ครอบคลุมการติดตั้ง, การยืนยันตัวตน, และชุดคำสั่งทั้งหมด หากต้องการทดลองใช้ ดาวน์โหลด Apidog
2. Newman (ตัวรันของ Postman)
Newman เป็น command-line collection runner อย่างเป็นทางการของ Postman หากทีมของคุณใช้งาน Postman อยู่แล้ว Newman คือทางเลือกที่ง่ายที่สุด: ส่งออกคอลเลกชันและสภาพแวดล้อม จากนั้นรันใน CI
newman run collection.json -e env.json -r cli,json
มันรองรับตัวรายงานหลายรูปแบบ (CLI, JSON, JUnit, HTML ผ่านปลั๊กอิน), ไฟล์ข้อมูลสำหรับการทำซ้ำ, และสัญญา exit-code ที่เสถียรสำหรับ pipelines
ข้อดี:
- เป็นผู้ใหญ่, มีเอกสารประกอบอย่างกว้างขวาง, ระบบนิเวศขนาดใหญ่
- เข้ากันได้กับ Postman ระดับสูงสุด
- ตัวรายงานที่ยืดหยุ่นและการวนซ้ำแบบ data-driven
ข้อเสีย:
- เช่นเดียวกับ Hoppscotch CLI มันเป็นเพียง runner เท่านั้น ไม่มีเลเยอร์การออกแบบหรือเอกสาร
- ผูกติดอยู่กับรูปแบบคอลเลกชันของ Postman และโมเดลสคริปต์
- คุณยังคงต้องส่งออก JSON เพื่อใช้งาน
สำหรับการเปรียบเทียบโดยตรงกับแนวทางของ Apidog โปรดดู Apidog CLI vs Newman
3. inso (Insomnia CLI โดย Kong)
inso เป็นส่วนเสริม command-line ของ Insomnia client โอเพ่นซอร์สของ Kong มันทำในสิ่งที่ Hoppscotch CLI ทำไม่ได้ นั่นคือการตรวจสอบความถูกต้องของ OpenAPI specs (lints OpenAPI specs) การตรวจสอบนี้ทำงานบน Spectral ซึ่งเป็น Stoplight OpenAPI linter ดังนั้นหากการควบคุมคุณภาพของ specs ใน CI มีความสำคัญสำหรับคุณ inso เป็นคู่แข่งที่แท้จริง
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
inso อ่านจากไดเรกทอรี .insomnia (สร้างโดย Git Sync ของ Insomnia) หรือไดเรกทอรีข้อมูลของแอป และอ้างอิงถึงชุดทดสอบและ specs ด้วยชื่อ คุณสามารถติดตั้งได้ด้วย brew install inso หรือ docker pull kong/inso:latest
ข้อดี:
- การตรวจสอบ OpenAPI ที่แท้จริงผ่าน Spectral
- รันการทดสอบและคอลเลกชัน, ส่งออก specs, ทั้งหมดนี้จากเทอร์มินัล
- ช่องทางการติดตั้งผ่าน Brew และ Docker
ข้อเสีย:
- อ้างอิงทรัพยากรด้วยชื่อ ซึ่งอาจเปราะบางในการเขียนสคริปต์
- Insomnia 8 ได้เปิดตัวบัญชีคลาวด์/การเข้าสู่ระบบที่จำเป็นในปี 2023 ซึ่งก่อให้เกิดกระแสต่อต้าน และมีเหตุการณ์การย้ายข้อมูลและการสูญหายของข้อมูลที่เกี่ยวข้องกับการเปลี่ยนแปลงนั้น เป็นสิ่งสำคัญที่ควรรู้หากคุณกำลังจะนำระบบนิเวศนี้มาใช้ใหม่
หากคุณกำลังพิจารณา Insomnia ในวงกว้างขึ้น Apidog vs Insomnia และ best Insomnia app alternatives เป็นบทความที่ควรอ่านต่อ นอกจากนี้ยังมีการเปรียบเทียบเชิงลึกระหว่าง Apidog CLI vs inso (Insomnia CLI)
4. Step CI (การทดสอบ API แบบโอเพ่นซอร์สใน YAML)
Step CI เป็นเครื่องมือคุณภาพ API แบบโอเพ่นซอร์สที่กำหนดการทดสอบในรูปแบบ YAML แบบประกาศ (declarative YAML) แทนที่จะเป็น JS แบบสคริปต์ คุณอธิบายคำขอและการตอบกลับที่คาดหวัง และมันจะทำการตรวจสอบ มันรองรับ REST, GraphQL, และ gRPC ซึ่งครอบคลุมโปรโตคอลได้กว้างกว่า collection runners ส่วนใหญ่
npx stepci run workflow.yml
ข้อดี:
- YAML แบบประกาศ, อ่านง่ายในการควบคุมเวอร์ชัน
- รองรับหลายโปรโตคอล (REST, GraphQL, gRPC)
- ไม่ขึ้นกับ GUI, การกำหนดค่าทั้งหมดอยู่ใน repository ของคุณ
ข้อเสีย:
- ชุมชนและระบบนิเวศขนาดเล็กกว่า
- ไม่มีเลเยอร์การออกแบบ, การจำลอง (mock), หรือเอกสาร
- คุณเขียนการทดสอบด้วยมือใน YAML แทนที่จะบันทึก
Step CI เหมาะสมหากคุณต้องการการทดสอบที่เป็นมิตรกับ Git, อ่านง่าย และไม่ต้องการ UI เลย
5. Hurl (การทดสอบ HTTP ด้วยข้อความธรรมดา)
Hurl รันคำขอ HTTP ที่เขียนในรูปแบบข้อความธรรมดาที่เรียบง่าย และยืนยันผลการตอบกลับ มันสร้างขึ้นบน libcurl, ทำงานได้รวดเร็ว, และให้ผลลัพธ์ที่สะอาด ไม่มีสคริปต์และไม่มีคอลเลกชัน JSON มีเพียงไฟล์ .hurl ที่คุณสามารถเปรียบเทียบความแตกต่างใน pull request ได้
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
รันด้วย:
hurl --test health.hurl
ข้อดี:
- น้ำหนักเบามาก, ไบนารีเดียว, รวดเร็ว
- ไฟล์ข้อความธรรมดาที่อ่านเหมือนเอกสาร
- ยอดเยี่ยมสำหรับการทดสอบ smoke tests และ health checks ใน CI
ข้อเสีย:
- ระดับต่ำกว่าเฟรมเวิร์กการทดสอบเต็มรูปแบบ
- ไม่มีคุณสมบัติการออกแบบ, การจำลอง (mock), หรือเอกสาร
- ไม่สะดวกเท่าสำหรับการทดสอบที่ซับซ้อน, แบบต่อเนื่อง, หรือแบบ data-driven
Hurl โดดเด่นสำหรับการตรวจสอบสัญญาและ smoke checks ที่รวดเร็วและอ่านง่าย มันไม่ได้พยายามจะเป็นแพลตฟอร์ม
ตารางเปรียบเทียบ
| เครื่องมือ | ลิขสิทธิ์ | จุดเน้นหลัก | Data-driven | การตรวจสอบ Spec | การออกแบบ/จำลอง/เอกสาร | รูปแบบรายงาน |
|---|---|---|---|---|---|---|
| Apidog CLI | เชิงพาณิชย์ (เวอร์ชันฟรี) | แพลตฟอร์มเต็มรูปแบบ + การทดสอบ CLI | มี (CSV/JSON) | ไม่มี (ตรวจสอบเมื่อนำเข้า) | มี | CLI, HTML, JSON, คลาวด์ |
| Hoppscotch CLI | โอเพ่นซอร์ส | Collection runner | มี (การวนซ้ำ CSV) | ไม่มี | ไม่มี | CLI, JUnit |
| Newman | โอเพ่นซอร์ส | Postman runner | มี (ไฟล์ข้อมูล) | ไม่มี | ไม่มี | CLI, JSON, JUnit, HTML |
| inso | โอเพ่นซอร์ส | Insomnia runner + linter | จำกัด | มี (Spectral) | บางส่วน (เอกสารการออกแบบ) | CLI, JUnit |
| Step CI | โอเพ่นซอร์ส | การทดสอบ API ด้วย YAML | มี | ไม่มี | ไม่มี | CLI, JUnit |
| Hurl | โอเพ่นซอร์ส | การทดสอบ HTTP ด้วยข้อความธรรมดา | ผ่านการสร้างเทมเพลต | ไม่มี | ไม่มี | CLI, JUnit, HTML |
วิธีเลือก
- คุณต้องการเครื่องมือเดียวสำหรับการออกแบบไปจนถึงการทดสอบ: Apidog CLI มันช่วยลดขั้นตอนการส่งออก JSON แล้วจึงรัน และเก็บทรัพยากร API และการทดสอบของคุณไว้ในระบบเดียวกัน
- ทีมของคุณใช้ Postman อยู่แล้ว: Newman มีค่าใช้จ่ายในการเปลี่ยนผ่านต่ำที่สุด
- คุณต้องการการตรวจสอบ OpenAPI (linting) ใน CI: inso เนื่องจากใช้ Spectral
- คุณต้องการการทดสอบที่เป็นมิตรกับ Git และเป็นแบบประกาศ: Step CI (YAML) หรือ Hurl (ข้อความธรรมดา)
- คุณพอใจกับ OSS runner ฟรีและแค่ต้องการหลีกเลี่ยง Node 22: เครื่องมือใดๆ ข้างต้น เนื่องจาก Newman, Step CI, และ Hurl ไม่มีข้อกำหนดนั้นร่วมกัน
หากเหตุผลหลักที่คุณจะเปลี่ยนคือข้อจำกัดของ collection-runner มากกว่าความรำคาญเพียงอย่างเดียว แนวทางแบบรวม (integrated route) คือสิ่งที่คุณควรพิจารณาเป็นอันดับแรก โปรดดู Apidog CLI vs Postman CLI และ Apidog CLI CI/CD pipeline สำหรับวิธีการที่ฝั่งการทดสอบเข้ากับ pipeline จริงๆ และ Apidog CLI test reports สำหรับตัวเลือกตัวรายงาน
คำถามที่พบบ่อย
Hoppscotch CLI ฟรีหรือไม่? ฟรี @hoppscotch/cli เป็นโอเพ่นซอร์สและใช้งานได้ฟรี มันรันคอลเลกชัน, รันสคริปต์ทดสอบ, และส่งออกรายงาน JUnit ทางเลือกเหล่านี้ไม่ได้เป็นเพราะ Hoppscotch มีราคาแพง แต่เป็นเพราะต้องการอะไรที่มากกว่าแค่ runner
ทางเลือกที่ง่ายที่สุดสำหรับ Hoppscotch CLI หากฉันไม่ต้องการ Node v22 คืออะไร? Hurl เป็นไบนารีเดียวที่ไม่มีการพึ่งพา Node เลย inso ติดตั้งผ่าน Homebrew หรือ Docker ส่วน Step CI รันผ่าน npx แต่ไม่ได้ถูกจำกัดไว้ที่ Node 22 เหมือน Hoppscotch CLI ในปัจจุบัน
ฉันสามารถย้ายคอลเลกชัน Hoppscotch ที่มีอยู่ไปยังเครื่องมืออื่นได้หรือไม่? ได้ เครื่องมือส่วนใหญ่รองรับคอลเลกชันที่ส่งออกหรือ OpenAPI สำหรับแนวทางแบบรวม (integrated route) คู่มือ migrate Hoppscotch CLI to Apidog CLI จะแนะนำการนำเข้าและการรันชุดทดสอบของคุณใหม่
Apidog CLI ตรวจสอบ OpenAPI specs เหมือน inso หรือไม่? ไม่ได้ Apidog ตรวจสอบความถูกต้องของ specs เมื่อนำเข้า แต่ไม่มีคำสั่ง linter แบบเดี่ยว หากการบังคับใช้ style-guide แบบ Spectral ใน CI เป็นข้อกำหนดที่เข้มงวด ให้ใช้ Apidog ร่วมกับ inso หรือใช้ Apidog CLI vs Redocly CLI เพื่อเปรียบเทียบตัวเลือกที่เน้นการตรวจสอบ
ทางเลือกใดดีที่สุดสำหรับ CI pipeline? ทั้งหมดนี้จะคืนค่า exit code ที่ไม่ใช่ศูนย์เมื่อล้มเหลว ดังนั้นทั้งหมดจึงทำงานใน CI ได้ ปัจจัยในการตัดสินใจคือสิ่งอื่นที่คุณต้องการ: การรันแบบบริสุทธิ์เหมาะกับ Newman หรือ Hurl; แหล่งข้อมูลเดียวสำหรับการออกแบบและการทดสอบเหมาะกับ Apidog CLI; การควบคุม spec เหมาะกับ inso
Hoppscotch CLI ทำงานของมันได้ดี หากงานนั้นเป็นสิ่งเดียวที่คุณต้องการก็ใช้ต่อไป แต่หากคุณต้องการรวมการออกแบบ, การจำลอง (mocking), เอกสาร, และการทดสอบเข้าไว้ในเวิร์กโฟลว์เดียวแทนที่จะต้องเชื่อมต่อ runner หลายตัว แพลตฟอร์มแบบรวม (integrated platform) คือทางเลือกที่เหมาะสม เริ่มต้นด้วย คู่มือฉบับสมบูรณ์ของ Apidog CLI จากนั้น ดาวน์โหลด Apidog และรันสถานการณ์แรกของคุณ