หากคุณรัน Insomnia ใน CI คุณจะรู้จัก inso. มันเป็นเครื่องมือคอมมานด์ไลน์คู่หูสำหรับไคลเอนต์ Insomnia API แบบโอเพนซอร์สของ Kong และมันสามารถทำสิ่งที่เป็นประโยชน์สามอย่างจากเทอร์มินัล: รันชุดทดสอบ (test suites), รันชุดคอลเล็กชันคำขอ (request collections) และตรวจสอบ OpenAPI specs ด้วย Spectral สำหรับหลายทีม แค่นั้นก็เพียงพอแล้ว แต่สำหรับบางทีม ปัญหาจะเริ่มปรากฏเร็วขึ้น
คู่มือนี้จะอธิบายว่า inso คืออะไร ทำไมทีมถึงเริ่มมองหา ทางเลือกอื่นของ inso และเครื่องมือใดที่สามารถใช้แทนได้ ขึ้นอยู่กับงานที่คุณต้องการทำ บางเครื่องมือเป็นแพลตฟอร์ม API แบบเต็มรูปแบบ บางเครื่องมือเป็นเพียงรันเนอร์ขนาดเล็กที่มีวัตถุประสงค์เดียว ไม่มีเครื่องมือใดที่สามารถใช้แทนกันได้อย่างสมบูรณ์แบบ ดังนั้นคำตอบที่ซื่อสัตย์สำหรับคำถาม "อะไรคือ ทางเลือกที่ดีที่สุดสำหรับ insomnia cli" คือ "ขึ้นอยู่กับว่าคุณใช้ inso ทำอะไรอยู่ในปัจจุบัน"
inso ทำอะไร และปัญหาเริ่มจากตรงไหน
inso อ่านจากไดเรกทอรี .insomnia ในไดเรกทอรีการทำงานของคุณ (สร้างโดย Insomnia’s Git Sync) หรือจากไดเรกทอรีข้อมูลของแอป Insomnia หากมีการติดตั้งแอปเดสก์ท็อป คุณอ้างอิง specs และ suites ด้วยชื่อ ไม่ใช่ด้วยพาธไฟล์:
inso run test "My API Test Suite" --env "Staging"
inso run collection "Smoke Tests" --env "Staging"
inso lint spec "Petstore Design Doc"
inso export spec "Petstore Design Doc" --output openapi.yaml
การติดตั้งทำได้ง่ายดาย ทั้ง Homebrew (brew install inso), Docker image (docker pull kong/inso:latest) หรือดาวน์โหลดไฟล์ ZIP โดยตรงสำหรับ Windows, Linux และ macOS Spectral ซึ่งเป็น Stoplight OpenAPI linter ขับเคลื่อน inso lint spec การตรวจสอบนี้เป็นจุดแข็งที่แท้จริง และควรพิจารณาก่อนที่คุณจะเปลี่ยนไปใช้เครื่องมืออื่น
แล้วทำไมถึงมองหา ทางเลือกอื่นนอกเหนือจาก inso? มีเหตุผลที่เกิดขึ้นซ้ำๆ ดังนี้:
- การผูกติดกับฐานข้อมูลแอป Insomnia. แหล่งข้อมูลหลักของการทดสอบของคุณอยู่ภายในไดเรกทอรี
.insomniaหรือโฟลเดอร์ข้อมูลของแอป หากคุณไม่ได้ใช้แอปเดสก์ท็อป โมเดลนี้จะรู้สึกว่าย้อนหลัง - การอ้างอิงตามชื่อ. Suites และ specs ถูกอ้างอิงด้วยชื่อที่แสดง หากเปลี่ยนชื่อ suite ใน GUI คำสั่ง CI ของคุณจะหยุดทำงานโดยไม่มีการแจ้งเตือน ชื่อไม่ใช่ตัวระบุที่เสถียร
- เรื่องบัญชีคลาวด์. Insomnia 8 (2023) ได้เปิดตัวบัญชีการเข้าสู่ระบบคลาวด์ที่จำเป็น ซึ่งได้รับการต่อต้านอย่างรุนแรง นอกจากนี้ยังเกิดเหตุการณ์ข้อมูลสูญหายและการย้ายข้อมูลในช่วงเวลานั้น ทีมที่ได้รับผลกระทบเริ่มมองหาเครื่องมือที่ไม่ผูกข้อมูลคำขอของตนเข้ากับบัญชีผู้จำหน่าย
- การแยกการตรวจสอบ (linting) กับการทดสอบ (testing).
insoรวมการตรวจสอบ spec และการทดสอบคำขอเข้าด้วยกัน หากคุณต้องการเพียงอย่างใดอย่างหนึ่ง คุณอาจต้องการเครื่องมือที่ทำสิ่งนั้นโดยไม่ต้องมีอีกอย่าง
หากการตรวจสอบ OpenAPI เป็นเหตุผลหลักที่คุณใช้ inso การเปลี่ยนเครื่องมืออาจทำให้คุณเสียมากกว่าที่จะได้ Most runners ด้านล่างนี้มุ่งเน้นไปที่การดำเนินการคำขอและการยืนยัน ไม่ใช่การตรวจสอบสไตล์ตามแบบ Spectral โปรดจำข้อแตกต่างนี้ไว้ขณะที่คุณอ่าน
ทางเลือกอื่นโดยสรุป
| เครื่องมือ | ประเภท | รูปแบบแหล่งที่มา | ขับเคลื่อนด้วยข้อมูล | ผู้รายงานผล | โอเพนซอร์ส | เหมาะที่สุดสำหรับ |
|---|---|---|---|---|---|---|
| Apidog CLI | รันเนอร์แพลตฟอร์มเต็มรูปแบบ | โปรเจกต์ Apidog / การนำเข้า OpenAPI | ใช่ (-d CSV/JSON) |
CLI, HTML, JSON | ไม่ (มีรุ่นฟรี) | แพลตฟอร์มเดียว: ออกแบบ, Mock, เอกสาร, ทดสอบ |
| Newman | รันเนอร์ Postman collection | Postman collection JSON | ใช่ (-d CSV/JSON) |
CLI, HTML, JSON | ใช่ | Postman collections ที่มีอยู่แล้ว |
| Hoppscotch CLI | รันเนอร์ OSS collection | Hoppscotch collection JSON / cloud ID | ใช่ (iteration data CSV) | CLI, JUnit XML | ใช่ | ฟรี, มีไปป์ไลน์ OSS ที่โฮสต์เองได้ |
| Step CI | ตัวทดสอบ API แบบ Declarative | ไฟล์ YAML / JSON workflow | จำกัด | CLI, JUnit | ใช่ | การทดสอบแบบ Spec-driven, config-as-code |
| Hurl | รันเนอร์ HTTP แบบข้อความธรรมดา | ไฟล์ข้อความ .hurl |
ผ่านตัวแปร | CLI, JUnit, HTML | ใช่ | การยืนยัน HTTP ที่มีน้ำหนักเบา |
1. Apidog CLI (ตัวเลือกแบบครบวงจร)
Apidog เป็นแพลตฟอร์ม API แบบครบวงจรที่ครอบคลุมการออกแบบ, การดีบัก, การทดสอบ, การจำลอง (mocking) และเอกสาร Apidog CLI นำด้านการทดสอบมาสู่เทอร์มินัลและ CI/CD ของคุณ ซึ่งเป็นจุดที่แข่งขันโดยตรงกับ inso
apidog run จะดำเนินการสถานการณ์ทดสอบและคอลเล็กชันจากคอมมานด์ไลน์ รองรับการทดสอบแบบขับเคลื่อนด้วยข้อมูลด้วย -d (ชุดข้อมูล CSV หรือ JSON), สภาพแวดล้อมด้วย -e และผู้รายงานผลในรูปแบบ CLI, HTML และ JSON นอกจากนี้ยังสามารถอัปโหลดรายงานการทดสอบบนคลาวด์ด้วย --upload-report เพื่อให้ผลลัพธ์ไม่หายไปในบันทึกของ CI
apidog run --access-token <token> -t <scenario-id> -e <env-id>
apidog run -t <scenario-id> -d ./users.csv -r html,cli
apidog run -t <scenario-id> --upload-report
นอกเหนือจากการรันการทดสอบ Apidog CLI ยังจัดการทรัพยากร API ในรูปแบบโค้ด: การนำเข้า OpenAPI และการทำงานกับ endpoints, schemas, environments, branches และ merge requests จากเทอร์มินัล โมเดล branch-and-resource-as-code นี้ใกล้เคียงกับเวิร์กโฟลว์แบบ Git-native มากกว่ารูปแบบไดเรกทอรี .insomnia และเป็นเหตุผลที่ทีมเลือก Apidog เมื่อต้องการเครื่องมือเดียวแทนที่จะเป็นชุดเครื่องมือที่ประกอบเข้าด้วยกัน
หมายเหตุอย่างตรงไปตรงมา: Apidog CLI ไม่มี เครื่องมือ OpenAPI linter แบบสแตนด์อโลน, style-guide, split, join หรือ bundle command มันตรวจสอบ specs เมื่อนำเข้า แต่ไม่ได้ตรวจสอบ (lint) เหมือนที่ inso ทำด้วย Spectral หากการตรวจสอบ (linting) ผ่านเทอร์มินัลเป็นความต้องการหลักของคุณ นี่เป็นช่องว่างที่สำคัญ และ inso (หรือ Redocly CLI) ยังคงได้เปรียบในจุดนี้ สิ่งที่ Apidog ชนะคือการรวมเข้าด้วยกัน: การออกแบบ, การจำลอง (mock), เอกสาร และการทดสอบอยู่ในที่เดียว โดยมีการรันที่ขับเคลื่อนด้วยข้อมูลและผู้รายงานผลหลายรูปแบบในตัว
ข้อดี
- แพลตฟอร์มเดียวสำหรับการออกแบบ, การจำลอง, เอกสาร และการทดสอบ ไม่ใช่เครื่องมือแยกกันที่นำมาเชื่อมต่อกัน
- การรันที่ขับเคลื่อนด้วยข้อมูล (
-d), รูปแบบผู้รายงานผลสามรูปแบบ, สภาพแวดล้อม, รายงานบนคลาวด์ - ทรัพยากรและ branches ถูกจัดการเป็นโค้ดจาก CLI
ข้อเสีย
- ไม่มี spec linter แบบสแตนด์อโลน (ตรวจสอบเมื่อนำเข้า แต่ไม่ตรวจสอบเหมือน Spectral)
- เป็นรุ่นฟรีมากกว่าโอเพนซอร์สแบบเต็มรูปแบบ
หากคุณกำลังเปรียบเทียบ terminal runners แบบตัวต่อตัว คู่มือ Apidog CLI ฉบับสมบูรณ์ จะแนะนำการตั้งค่า และมีการวิเคราะห์โดยตรง เช่น Apidog CLI vs Newman และ Apidog CLI vs Postman CLI สำหรับการนำไปใช้งานในระบบอัตโนมัติ โปรดดู คู่มือ GitHub Actions
2. Newman (รันเนอร์ Postman CLI)
Newman เป็นรันเนอร์คอลเล็กชันคอมมานด์ไลน์โอเพนซอร์สของ Postman หากทีมของคุณใช้ Postman อยู่แล้ว นี่คือ ทางเลือกอื่นของ inso cli ที่ชัดเจน เพราะมันรันคอลเล็กชันที่คุณสร้างไว้แล้ว
newman run collection.json -e staging.json -d data.csv -r cli,html,json
Newman รองรับการวนซ้ำที่ขับเคลื่อนด้วยข้อมูลด้วย -d, ไฟล์สภาพแวดล้อมด้วย -e และผู้รายงานผลในรูปแบบ CLI, HTML และ JSON มันเป็นเครื่องมือที่เติบโตเต็มที่ มีเอกสารประกอบที่ดี และเป็นที่นิยมในตัวอย่าง CI
ข้อดี
- รัน Postman collections ที่มีอยู่แล้วได้โดยไม่ต้องปรับแก้
- โอเพนซอร์ส, มีชุมชนขนาดใหญ่, มีตัวอย่าง CI มากมาย
- ระบบผู้รายงานผลที่แข็งแกร่ง
ข้อเสีย
- ผูกติดกับรูปแบบ Postman collection และโมเดลการซิงค์
- ไม่มีการตรวจสอบ (linting) OpenAPI เลย
- คุณจัดการคอลเล็กชันในแอป Postman ไม่ใช่ในรูปแบบไฟล์ spec ธรรมดา
สำหรับการเปรียบเทียบแบบเจาะลึกว่า Newman สิ้นสุดที่ใดและแพลตฟอร์มรันเนอร์เริ่มต้นที่ใด การเปรียบเทียบ Apidog CLI vs Newman ครอบคลุมผู้รายงานผล, การรันที่ขับเคลื่อนด้วยข้อมูล และการรายงานบนคลาวด์
3. Hoppscotch CLI (รันเนอร์โอเพนซอร์ส)
Hoppscotch เป็นระบบนิเวศ API แบบโอเพนซอร์ส (เว็บ, เดสก์ท็อป, CLI และสามารถโฮสต์เองได้) ที่ถูกวางตำแหน่งให้เป็นทางเลือกสำหรับ Postman และ Insomnia CLI ของมันคือ @hoppscotch/cli ใช้รันคอลเล็กชันใน CI
การติดตั้งต้องใช้ Node.js v22 หรือใหม่กว่า (ผู้ใช้ Node 20 ยังคงใช้ CLI v0.26.0):
npm i -g @hoppscotch/cli
hopp test ./collection.json -e ./env.json -d 100
hopp test <collection-id> --token <pat> --server https://hoppscotch.example.com
hopp test ./collection.json --reporter-junit ./report.xml
hopp test จะรันคำขอทั้งหมดในคอลเล็กชันซ้ำๆ ดำเนินการสคริปต์ pre-request และ test (suites pw.test(), cases pw.expect()) และตรวจสอบการตอบกลับ มันจะออกด้วยค่าที่ไม่ใช่ศูนย์หากมีการยืนยันใดๆ ล้มเหลว แฟล็กครอบคลุมสภาพแวดล้อม (-e), การหน่วงเวลา (-d), โทเค็นการเข้าถึงส่วนบุคคล (--token), เซิร์ฟเวอร์ที่โฮสต์เอง (--server), เอาต์พุต JUnit XML (--reporter-junit) และการวนซ้ำที่ขับเคลื่อนด้วยข้อมูล (--iteration-count, --iteration-data)
ข้อดี
- โอเพนซอร์สอย่างสมบูรณ์และสามารถโฮสต์เองได้ ไม่ต้องมีบัญชีผู้จำหน่ายที่จำเป็น
- เป็นรันเนอร์ OSS ฟรีจริงพร้อมการรายงาน JUnit และการวนซ้ำที่ขับเคลื่อนด้วยข้อมูล
- การอ้างอิงคอลเล็กชันบนคลาวด์หรือโฮสต์เอง
ข้อเสีย
- ข้อกำหนด Node v22+ อาจเป็นปัญหาสำหรับ CI images รุ่นเก่า
- ระบบนิเวศมีขนาดเล็กกว่า Newman
- ไม่มีการตรวจสอบ (linting) OpenAPI
หากคุณกำลังพิจารณาเส้นทางโอเพนซอร์ส ทางเลือกอื่นของ Hoppscotch และ Postman vs Hoppscotch ให้ข้อมูลบริบทที่เป็นประโยชน์ และมีการวิเคราะห์โดยตรง Apidog CLI vs Hoppscotch CLI
4. Step CI (ตัวเลือกแบบ Declarative)
Step CI มีรูปแบบที่แตกต่างออกไป แทนที่จะชี้ไปยังคอลเล็กชันที่สร้างใน GUI คุณเขียนการทดสอบ API เป็นไฟล์ YAML หรือ JSON workflow แบบ declarative ที่อยู่ใน repo ของคุณ การทดสอบคือคอนฟิก ซึ่งสามารถตรวจสอบได้ใน pull requests เหมือนโค้ดอื่นๆ
version: "1.1"
name: Status check
tests:
health:
steps:
- name: GET health
http:
url: https://api.example.com/health
method: GET
check:
status: 200
สิ่งนี้น่าสนใจหากคุณพบว่าการอ้างอิงตามชื่อของ inso เปราะบาง ที่นี่ คำจำกัดความของการทดสอบคือไฟล์ และพาธไฟล์คือตัวระบุ Step CI รันได้ทั้งในเครื่องและใน CI และส่งออกผลลัพธ์ JUnit
ข้อดี
- การทดสอบเป็นไฟล์ declarative ใน repo ของคุณ สามารถตรวจสอบได้ใน PRs
- ไม่มีฐานข้อมูลแอป ไม่มี GUI dependency
- เหมาะสำหรับทีมที่เน้น spec-driven
ข้อเสีย
- โต้ตอบได้น้อยกว่ารันเนอร์ที่ใช้ GUI สำหรับการดีบักเฉพาะกิจ
- ชุมชนขนาดเล็ก; คุณเขียนด้วยมือมากขึ้น
- การสนับสนุนการขับเคลื่อนด้วยข้อมูลจำกัดมากกว่า Newman หรือ Apidog
Step CI เป็น insomnia cli replacement ที่สะอาดตาโดยเฉพาะสำหรับทีมที่ต้องการให้คำจำกัดความของการทดสอบอยู่ถัดจากโค้ดแอปพลิเคชันของตน แทนที่จะอยู่ภายในฐานข้อมูลของเครื่องมือ
5. Hurl (ตัวเลือกแบบข้อความธรรมดา)
Hurl เป็นเครื่องมือที่เรียบง่ายที่สุดในรายการนี้ คุณเขียนคำขอ HTTP และการยืนยันในไฟล์ข้อความ .hurl ธรรมดา และ Hurl ก็รันมัน ไม่มี GUI, ไม่มีฐานข้อมูล, ไม่มีบัญชี, แค่ข้อความเท่านั้น
GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.name" exists
รันด้วย hurl --test users.hurl มันสามารถต่อคำขอได้หลายคำขอ เก็บตัวแปรระหว่างคำขอ และรองรับรายงาน JUnit และ HTML สำหรับ smoke tests และ contract checks มันรวดเร็วและแทบไม่ต้องตั้งค่าใดๆ
ข้อดี
- รูปแบบข้อความธรรมดาที่ใช้งานง่ายมาก ควบคุมเวอร์ชันได้สะอาด
- ไม่มีแอป ไม่มีบัญชี มี footprint เล็กมากใน CI
- คำขอที่เชื่อมโยงกันพร้อมตัวแปรที่ถูกบันทึก
ข้อเสีย
- ไม่ใช่เฟรมเวิร์กการทดสอบเต็มรูปแบบ; สถานการณ์ที่ซับซ้อนจะยืดยาว
- ไม่มี GUI สำหรับคอลเล็กชัน ทำให้ผู้ใช้ที่ไม่คุ้นเคยกับ CLI เข้าถึงได้ยากกว่า
- ไม่มีการตรวจสอบ (linting) OpenAPI
จะเลือกอย่างไร
เลือกตามลักษณะงาน ไม่ใช่ตามแบรนด์:
- คุณต้องการเครื่องมือเดียวสำหรับการออกแบบ, การจำลอง (mock), เอกสาร และการทดสอบ. ใช้ Apidog CLI เป็นการทดแทนที่ครอบคลุมที่สุดและเป็นเพียงตัวเดียวที่ถือว่าทรัพยากรและ branches เป็นโค้ด
- คุณมี Postman collections อยู่แล้ว. ใช้ Newman ไม่ต้องสร้างสิ่งที่คุณมีอยู่แล้วขึ้นมาใหม่
- คุณต้องการโอเพนซอร์สเต็มรูปแบบและสามารถโฮสต์เองได้. ใช้ Hoppscotch CLI หรือ Hurl หากคุณต้องการสิ่งที่เบากว่ามาก
- คุณต้องการให้การทดสอบเป็นไฟล์ declarative ใน repo ของคุณ. ใช้ Step CI
- คุณส่วนใหญ่รัน
inso lint spec. คิดให้ดีก่อนที่จะเปลี่ยน การตรวจสอบ (linting) ด้วย Spectral เป็นจุดแข็งที่แท้จริงของinsoและรันเนอร์ส่วนใหญ่ในที่นี้ไม่สามารถแทนที่ได้ จับคู่รันเนอร์เข้ากับ Spectral โดยตรง หรือมองหา CLI สำหรับการตรวจสอบโดยเฉพาะ
หากคุณกำลังย้ายออกจากระบบนิเวศ Insomnia ที่กว้างขึ้น ไม่ใช่แค่ inso บทความเหล่านี้ก็คุ้มค่าที่จะอ่าน: Apidog vs Insomnia, ทางเลือกที่ดีที่สุดสำหรับแอป Insomnia และคู่มือการกู้คืนสำหรับ ข้อมูลสูญหายและการย้ายข้อมูลของ Insomnia สำหรับการย้ายจาก CLI ไป CLI โดยเฉพาะ โปรดดู ย้ายจาก inso ไปยัง Apidog CLI