Apidog CLI เทียบกับ inso (Insomnia CLI): เลือก API Test Runner ตัวไหนดีสำหรับ CI

การเลือกใช้ CLI test runner สำหรับ pipeline ของคุณขึ้นอยู่กับคำถามง่ายๆ: อะไรคือสิ่งที่คุณใช้รัน API ในการพัฒนาอยู่แล้ว และคุณต้องการให้สิ่งใดถูกทำให้เป็นอัตโนมัติใน CI? ถ้าทีมของคุณใช้ Insomnia, 'inso' คือคู่หูที่ชัดเจน แต่ถ้าคุณต้องการแพลตฟอร์มเดียวที่ใช้ในการออกแบบ จำลอง จัดทำเอกสาร และทดสอบ, Apidog CLI จะเปลี่ยนสมการทั้งหมด

แต่ละเครื่องมือคืออะไร

inso คือเครื่องมือคอมมานด์ไลน์คู่กับ Insomnia, ซึ่งเป็น API client แบบโอเพนซอร์สของ Kong โดยนำสามสิ่งนี้มาสู่เทอร์มินัลและ CI: การรันคอลเลกชันคำขอ, การรันชุดการทดสอบหน่วย, และการตรวจสอบความถูกต้องของ OpenAPI specs เครื่องมือนี้อ่านข้อมูลจากแหล่งเดียวกับที่แอป Insomnia บนเดสก์ท็อปของคุณใช้ ดังนั้น หากคุณสร้างคำขอใน GUI, inso จะรันคำขอเหล่านั้นในโหมด headless ได้

Apidog CLI คือ test runner สำหรับ Apidog ซึ่งเป็นแพลตฟอร์ม API แบบครบวงจรที่ครอบคลุมการออกแบบ, การดีบัก, การจำลอง, การจัดทำเอกสาร, และการทดสอบในเวิร์กสเปซเดียว CLI นี้จะดำเนินการตามสถานการณ์การทดสอบและคอลเลกชันจากโปรเจกต์, รองรับการรันที่ขับเคลื่อนด้วยข้อมูล, และสร้างรายงานในหลายรูปแบบ นอกจากนี้ยังสามารถนำเข้า OpenAPI และจัดการทรัพยากร API เช่น endpoint, schema, และ branch ในรูปแบบโค้ดได้

ความแตกต่างหลักจะปรากฏขึ้นก่อนที่คุณจะเริ่มรันการทดสอบแม้แต่ครั้งเดียว inso เป็น runner ที่เน้นการทำงานและเป็น linter สำหรับระบบนิเวศของ Insomnia ส่วน Apidog CLI เป็นส่วนหนึ่งของการทดสอบบนแพลตฟอร์มที่กว้างขวางกว่า

Apidog CLI vs inso: ตารางเปรียบเทียบ

ตารางนี้เป็นฉบับย่อ ส่วนด้านล่างจะอธิบายความแตกต่างที่สำคัญจริงๆ เมื่อคุณเชื่อมต่อเครื่องมือใดเครื่องมือหนึ่งเข้ากับ CI

การติดตั้ง: brew และ Docker เทียบกับตัวติดตั้ง Apidog

inso มีวิธีการติดตั้งหลายช่องทางที่ระบุไว้ วิธีที่พบบ่อยได้แก่:

# Homebrew
brew install inso

# Docker
docker pull kong/inso:latest

นอกจากนี้ยังมีไฟล์ดาวน์โหลดโดยตรงสำหรับ Windows, Linux และ macOS ในอดีต inso เคยอยู่บน npm ในชื่อ insomnia-inso แต่ Homebrew, Docker และการดาวน์โหลดโดยตรงคือเส้นทางที่ Kong แนะนำในปัจจุบัน อิมเมจ Docker มีประโยชน์สำหรับ CI runners ที่คุณไม่ต้องการจัดการ Node toolchain

Apidog CLI ติดตั้งจาก หน้าดาวน์โหลด Apidog และรันสถานการณ์ที่อยู่ในโปรเจกต์ Apidog ของคุณ เนื่องจาก test ถูกผูกไว้กับโปรเจกต์ CLI จะดึงคำจำกัดความปัจจุบันแทนที่จะอ่านโฟลเดอร์ในเครื่องที่คุณต้องซิงค์ด้วยตนเอง หากคุณต้องการคำแนะนำฉบับเต็ม คู่มือการติดตั้ง Apidog CLI และ คู่มือ CLI ฉบับสมบูรณ์ ครอบคลุมการตั้งค่าตั้งแต่ต้นจนจบ

แต่ละเครื่องมือรันอะไร และอ่านข้อมูลจากไหน

นี่คือความแตกต่างที่สำคัญที่สุดในการตัดสินใจเลือกระหว่าง apidog cli กับ insomnia cli

inso อ้างอิงถึง test suites และ specs ด้วยชื่อ คุณชี้ไปที่เอกสารการออกแบบหรือคอลเลกชันด้วยชื่อที่แสดงผล และมันจะค้นหาคำจำกัดความในไดเรกทอรี .insomnia ในไดเรกทอรีการทำงานของคุณ (ที่สร้างโดย Insomnia’s Git Sync) หรือในไดเรกทอรีข้อมูลของแอป Insomnia หากมีการติดตั้งแอปอยู่ คุณสามารถกำหนดตำแหน่งใหม่ได้ด้วย --workingDir หรือ --src

inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging

โมเดลที่อ้างอิงตามชื่อจะดูเรียบร้อยดีหากทีมของคุณ commit โฟลเดอร์ .insomnia และถือว่าเป็นแหล่งความจริง แต่นั่นหมายความว่า CI checkout ของคุณต้องมีโฟลเดอร์นั้นอยู่ และชื่อจะต้องคงที่

Apidog CLI รัน test scenarios ที่อยู่ในโปรเจกต์ Apidog คุณต้องยืนยันตัวตนด้วยการเข้าสู่ระบบหรือ Access Token จากนั้นรัน scenario หรือ collection กับ environment ที่เลือก คำจำกัดความมาจากโปรเจกต์ ดังนั้น scenario เดียวกันที่ทีมของคุณสร้างใน GUI คือสิ่งที่จะรันใน CI โดยไม่ต้อง commit โฟลเดอร์และคอยรักษาการซิงค์

apidog run -t <scenario-or-collection> -e <environment>

ทั้งสองโมเดลนั้นไม่มีโมเดลไหนที่ผิด inso เน้นโฟลเดอร์ในเครื่องที่ commit ไปยัง Git ส่วน Apidog เน้นโปรเจกต์ที่ซิงค์ไว้ เลือกโมเดลที่ตรงกับวิธีการที่ทีมของคุณใช้แชร์คำจำกัดความ API อยู่แล้ว

การทดสอบแบบขับเคลื่อนด้วยข้อมูล (Data-driven testing)

หากคุณจำเป็นต้องรันสถานการณ์เดียวกันกับข้อมูลอินพุตหลายชุด สิ่งนี้มีความสำคัญ

Apidog CLI รองรับการทดสอบแบบ data-driven โดยตรงด้วย -d โดยชี้ไปที่ชุดข้อมูล CSV หรือ JSON แต่ละแถวจะกลายเป็นรอบการทำงานพร้อมกับตัวแปรของตัวเอง ทำให้ scenario เดียวสามารถครอบคลุมกรณีทดสอบได้หลายสิบกรณี

apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv

รูปแบบเต็ม รวมถึงวิธีการจับคู่ตัวแปรกับคอลัมน์ อยู่ในหัวข้อ การทดสอบแบบ Data-driven ด้วย Apidog CLI

inso ไม่ได้เปิดเผย flag สำหรับการทดสอบแบบ data-driven ในคำสั่งรันของมัน คุณสามารถกำหนดพารามิเตอร์ผ่าน environments และคุณสามารถขับเคลื่อนการทำซ้ำได้โดยการเขียนสคริปต์รอบ inso ใน CI job ของคุณ แต่การทำซ้ำแบบแถวต่อแถวด้วย CSV/JSON ไม่ใช่คุณสมบัติ CLI ระดับเฟิร์สคลาสเหมือนใน Apidog หากการทำซ้ำกับชุดข้อมูลเป็นหัวใจสำคัญของชุดการทดสอบของคุณ นี่คือความแตกต่างที่แท้จริงที่ควรพิจารณา

Reporters: สิ่งที่คุณจะได้รับกลับมา

รายงานคือวิธีที่ CI บอกคุณว่าเกิดอะไรขึ้น เครื่องมือทั้งสองจะทำให้การ build ล้มเหลวหากมี assertion ที่ไม่ผ่าน แต่มีความแตกต่างในรูปแบบ output

Apidog CLI สร้างรายงานในรูปแบบ CLI, HTML, และ JSON รูปแบบ CLI เหมาะสำหรับการสแกน log อย่างรวดเร็ว, HTML ให้ artifact ที่สามารถแชร์ได้, และ JSON สำหรับ feed ไปยัง dashboard หรือเครื่องมืออื่นๆ คุณยังสามารถ push ผลลัพธ์ไปยังคลาวด์ด้วย --upload-report เพื่อรับรายงานที่โฮสต์และเชื่อมโยงได้ คู่มือรายงานการทดสอบ Apidog CLI จะอธิบายแต่ละรูปแบบ

inso พิมพ์ผลลัพธ์การทดสอบไปยังคอนโซลและส่งสัญญาณผ่าน/ไม่ผ่านด้วยรหัสสถานะ (exit code) ซึ่งเป็นสิ่งที่ระบบ CI ส่วนใหญ่ใช้ สิ่งนี้ครอบคลุมความต้องการหลัก หากคุณต้องการ artifact HTML ที่สมบูรณ์หรือรายงานที่โฮสต์โดยไม่ต้องใช้เครื่องมือเพิ่มเติม Apidog จะให้คุณได้มากกว่าในจุดนี้

Linting: การเปรียบเทียบที่ตรงไปตรงมา

นี่คือจุดที่ inso มีข้อได้เปรียบอย่างแท้จริง และคงไม่ยุติธรรมที่จะแสร้งทำเป็นว่าไม่ใช่

inso ทำการ lint OpenAPI specs ด้วย inso lint spec และ linter ที่อยู่เบื้องหลังคือ Spectral ซึ่งเป็น OpenAPI linter ที่รู้จักกันดีของ Stoplight นั่นหมายความว่าคุณสามารถบังคับใช้ style guide, ตรวจจับปัญหา contract, และควบคุมการรวมโค้ดโดยอิงจากคุณภาพของ spec ได้ทั้งหมดจาก CLI เดียวกันที่ใช้รันการทดสอบของคุณ

inso lint spec "Payments API"
inso export spec "Payments API" --output openapi.yaml

สำหรับทีมที่ปฏิบัติงานแบบ spec-first design และต้องการให้มีการบังคับใช้กฎ lint ใน CI นี่คือเหตุผลที่แข็งแกร่งและแท้จริงในการเลือกใช้ inso

ตอนนี้มาดูข้อดีของ Apidog อย่างตรงไปตรงมากันบ้าง Apidog CLI ไม่มี OpenAPI linter, style-guide, split, join, หรือ bundle command แยกต่างหาก Apidog ตรวจสอบ specs เมื่อคุณนำเข้า ซึ่งจะช่วยตรวจจับปัญหาเชิงโครงสร้าง แต่เป็นการตรวจสอบเมื่อนำเข้า ไม่ใช่คำสั่ง lint ที่คุณรันกับ style guide ใน CI อย่าคาดหวังว่า Apidog CLI จะมาแทนที่ Spectral หากการ lint contract ใน pipeline เป็นข้อกำหนดที่เข้มงวดและคุณไม่มีขั้นตอน Spectral แยกต่างหาก inso ครอบคลุมในจุดนี้ แต่ Apidog ไม่ได้

ในทางกลับกัน Apidog ได้รับตำแหน่งในการรวมระบบและการจัดการทรัพยากร ซึ่งเป็นส่วนถัดไป

ทรัพยากรและ Branch as code

Apidog CLI สามารถทำสิ่งหนึ่งที่ inso ทำไม่ได้: การจัดการทรัพยากร API เป็นโค้ด จากเทอร์มินัล คุณสามารถนำเข้า OpenAPI และทำงานกับ endpoint, schema, environment, branch และ merge request ได้ สิ่งนี้ช่วยให้คุณสามารถเขียนสคริปต์การเปลี่ยนแปลงการออกแบบ API และเชื่อมโยงเข้ากับการทำงานอัตโนมัติเดียวกับการรันการทดสอบ

inso ยังคงอยู่ในขอบเขตของมันในฐานะ runner และ linter มันสามารถส่งออก spec ได้ แต่ไม่ใช่ CLI สำหรับการจัดการทรัพยากรเพื่อแก้ไข endpoint หรือจัดการ branch

สำหรับทีมที่ต้องการให้คำจำกัดความ API และการรันทดสอบอยู่ภายใต้การควบคุมของ CLI เดียวกัน การจัดการทรัพยากรเป็นโค้ดของ Apidog ถือเป็นข้อได้เปรียบที่สำคัญ นั่นเป็นส่วนหนึ่งที่ทำให้การเลือก inso vs apidog มักจะกลายเป็นคำถามเกี่ยวกับแพลตฟอร์มมากกว่าคำถามเกี่ยวกับ runner

การรวมแพลตฟอร์ม, โอเพนซอร์ส และราคา

inso เป็นส่วนหนึ่งของระบบนิเวศโอเพนซอร์ส Insomnia เองก็เป็นโอเพนซอร์ส ซึ่งดึงดูดทีมที่ต้องการตรวจสอบหรือโฮสต์เครื่องมือของตนเอง ข้อควรทราบที่ตรงไปตรงมาสำหรับการวางแผน: Insomnia 8 ในปี 2023 ได้แนะนำบัญชีคลาวด์/การเข้าสู่ระบบที่จำเป็น ซึ่งสร้างความไม่พอใจ และมีเหตุการณ์การโยกย้ายและข้อมูลสูญหายในช่วงนั้น หากทีมของคุณพิจารณาเหตุการณ์เหล่านั้น บทความของเราเกี่ยวกับ การกู้คืนและการโยกย้ายข้อมูลที่สูญหายใน Insomnia และ วิธีการกู้คืนและส่งออกข้อมูล Insomnia ครอบคลุมรายละเอียดทั้งหมด ไม่มีสิ่งใดเปลี่ยนแปลงความจริงที่ว่า inso CLI เป็น runner ที่แข็งแกร่งและฟรี พร้อมกับการ linting ด้วย Spectral ในตัว

Apidog เป็นแพลตฟอร์มเชิงพาณิชย์ที่มี Free tier จุดเด่นของมันคือการรวมระบบ: คุณออกแบบ จำลอง จัดทำเอกสาร ดีบัก และทดสอบได้ในที่เดียว และ CLI เป็นส่วนการทำงานอัตโนมัติสำหรับเวิร์กสเปซนั้น คุณไม่จำเป็นต้องนำเครื่องมือออกแบบ เซิร์ฟเวอร์จำลอง และ runner มารวมกัน สำหรับมุมมองผลิตภัณฑ์ที่กว้างขึ้น ดูที่ Apidog vs Insomnia และ Insomnia vs Apidog หากคุณต้องการลองใช้ runner กับ API จริงก่อน วิธีการใช้ Insomnia เพื่อทดสอบ API และ การทดสอบ REST API จาก Command Line เป็นจุดเริ่มต้นที่ดี

การเชื่อมต่อ CI โดยสังเขป

เครื่องมือทั้งสองสามารถนำไปใช้ใน pipeline ได้ในลักษณะเดียวกัน: ติดตั้ง, ยืนยันตัวตนหรือชี้ไปยังข้อมูลของคุณ, รัน, และปล่อยให้ exit code เป็นตัวควบคุมการ build

# inso ใน CI
- run: brew install inso
- run: inso run test "Smoke Suite" --env "CI"

# Apidog CLI ใน CI
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json

หากคุณกำลังสร้างสิ่งนี้ คู่มือ Apidog CLI CI/CD pipeline และ GitHub Actions walkthrough ครอบคลุมการยืนยันตัวตน, การแคช, และการอัปโหลดรายงาน รายละเอียดการยืนยันตัวตนสำหรับ runner อยู่ใน คู่มือการยืนยันตัวตน Apidog CLI

คำตัดสิน

ไม่มีผู้ชนะคนเดียว คำตอบที่ตรงไปตรงมาขึ้นอยู่กับวิธีการทำงานของทีมคุณ

เลือก inso หากคุณใช้งาน Insomnia อยู่แล้ว, commit โฟลเดอร์ .insomnia, และต้องการให้มีการบังคับใช้ Spectral spec linting ใน CI ด้วยเครื่องมือเดียวกับที่ใช้รันการทดสอบของคุณ ระบบนิเวศโอเพนซอร์สและ linter ในตัวคือจุดแข็งที่แท้จริง และ runner ฟรีที่อ้างอิงตามชื่อเหมาะกับทีมที่ใช้ Insomnia เป็นหลัก

เลือก Apidog CLI หากคุณต้องการแพลตฟอร์มเดียวสำหรับการออกแบบ, จำลอง, จัดทำเอกสาร, และทดสอบ พร้อมด้วยการรันแบบ data-driven ผ่าน -d, รายงานที่หลากหลายยิ่งขึ้น (CLI, HTML, JSON, รวมถึงรายงานที่โฮสต์), และการจัดการทรัพยากรและ branch เป็นโค้ด คุณจะเสีย linter CLI แบบสแตนด์อโลนไป แต่คุณจะได้เวิร์กโฟลว์แบบบูรณาการที่สิ่งที่คุณออกแบบคือสิ่งที่คุณทดสอบ การย้ายการตั้งค่าที่มีอยู่ทำได้ง่ายดาย; ดูที่ ย้ายจาก inso (Insomnia CLI) ไปยัง Apidog CLI

พร้อมที่จะเปรียบเทียบด้วยตัวเองแล้วหรือยัง? ดาวน์โหลด Apidog และรัน scenario กับ API ของคุณเอง