Bruno คือไคลเอนต์ API แบบ Git-native, โอเพนซอร์ส และน้ำหนักเบา ซึ่งการออกแบบนี้ช่วยให้มันรวดเร็วและง่ายต่อการจัดการเวอร์ชัน แต่มันก็ทิ้งช่องโหว่ที่ทีมเจออย่างรวดเร็ว: ไม่มีวิธีจำลอง (mock) endpoint ที่ยังไม่มีอยู่ หากคุณเคยค้นหาทางเลือกเซิร์ฟเวอร์จำลอง Bruno คู่มือนี้จะอธิบายว่าทำไมช่องโหว่นี้จึงมีอยู่, วิธีแก้ไขที่ผู้คนใช้, และวิธีการสร้างเซิร์ฟเวอร์จำลองได้โดยตรงจาก OpenAPI spec ของคุณ
คำตอบสั้น ๆ ก่อน: Bruno ไม่มีเซิร์ฟเวอร์จำลองในตัว คุณสามารถส่งคำขอและเขียนการทดสอบได้ แต่คุณไม่สามารถตั้งค่า endpoint ปลอมที่ส่งคืนการตอบสนองตัวอย่างได้ ในการจำลอง คุณต้องใช้เครื่องมือภายนอกหรือสร้างเซิร์ฟเวอร์ด้วยตัวเอง
ทำไมคุณถึงต้องการเซิร์ฟเวอร์จำลอง
เซิร์ฟเวอร์จำลองจะส่งคืนการตอบสนองที่สมจริงสำหรับ endpoint ที่ยังไม่ได้สร้าง, ไม่เสถียร, หรือยากที่จะเรียกใช้งานได้ตามต้องการ ซึ่งช่วยปลดล็อกสิ่งต่างๆ ดังนี้:
- การพัฒนาแบบขนาน. ทีมส่วนหน้าและมือถือสร้างตามสัญญา (contract) ในขณะที่ส่วนหลังยังอยู่ระหว่างการพัฒนา ไม่มีใครต้องรอ
- การทดสอบเส้นทางข้อผิดพลาด. API จริงไม่ค่อยส่ง 429 หรือ 503 มาให้คุณเมื่อคุณต้องการ การจำลองจะส่งคืนสถานะ, เฮดเดอร์, หรือเนื้อหาที่ผิดรูปแบบได้ตามคำสั่ง
- การสาธิตและต้นแบบ. แสดงขั้นตอนการทำงานโดยไม่ต้องมีแบ็กเอนด์จริง, ฐานข้อมูล, หรือข้อมูลประจำตัว
- CI ที่เสถียร. การทดสอบที่ใช้การจำลองจะไม่ล้มเหลวเพราะเซิร์ฟเวอร์ staging หยุดทำงานหรือถูกจำกัดอัตรา (rate-limited)
นี่คือสถานการณ์ความล้มเหลวที่การจำลองช่วยให้คุณทดสอบได้อย่างตั้งใจ แทนที่จะรอให้มันเกิดขึ้นในโปรดักชัน:
| สถานการณ์ | สิ่งที่การจำลองส่งคืน | ทำไมถึงยากที่จะทำได้ด้วยวิธีอื่น |
|---|---|---|
| เกินขีดจำกัดอัตรา | 429 + เฮดเดอร์ Retry-After |
แบ็กเอนด์ไม่ค่อยจำกัดอัตราตามต้องการ |
| เซิร์ฟเวอร์หยุดทำงาน | 500 / 503 |
ไม่สามารถทำให้ staging เสียหายเพียงเพื่อทดสอบได้ |
| การตอบสนองช้า | เนื้อหาที่ล่าช้า | ยากที่จะจำลองความหน่วงเวลาจริง |
| ชุดผลลัพธ์ว่างเปล่า | 200 พร้อม [] |
ขึ้นอยู่กับสถานะข้อมูลที่เฉพาะเจาะจง |
| เพย์โหลดผิดรูปแบบ | เนื้อหาขาดฟิลด์ที่จำเป็น | การตรวจสอบความถูกต้องของแบ็กเอนด์มักจะป้องกันได้ |
Bruno มีเซิร์ฟเวอร์จำลองหรือไม่?
ไม่มี. Bruno มุ่งเน้นไปที่การส่งคำขอ, การจัดระเบียบคอลเลกชันเป็นไฟล์ธรรมดา, และการรัน assertion ไม่มีเซิร์ฟเวอร์จำลองในตัว และไม่มีการตั้งค่าที่เปลี่ยนคำขอที่บันทึกไว้ให้เป็นสตับที่ใช้งานได้ นั่นคือการเลือกขอบเขตโดยเจตนา ไม่ใช่การมองข้าม แต่หมายความว่าการจำลองอยู่ภายนอกเครื่องมือ
ในทางปฏิบัติ ผู้ใช้ Bruno แก้ไขช่องว่างนี้ได้สองวิธี:
- เครื่องมือจำลองภายนอก. ตั้งค่าบริการแยกต่างหาก เช่น Mockoon, WireMock, Prism, หรือ json-server กำหนดการตอบสนองที่นั่น จากนั้นชี้ Bruno ไปยัง URL นั้น สองเครื่องมือ สองแหล่งข้อมูลความจริง
- เซิร์ฟเวอร์ที่สร้างเอง. เขียนแอป Express, Flask, หรือ FastAPI ขนาดเล็กที่ส่งคืน JSON ที่เตรียมไว้ ง่ายสำหรับ endpoint เดียว แต่ยุ่งยากในการบำรุงรักษาเมื่อ API มีขนาดใหญ่ขึ้น
ทั้งสองวิธีใช้ได้ผล ทั้งสองเพิ่มส่วนประกอบที่เคลื่อนไหวที่อยู่นอกคอลเลกชันของคุณ
ต้นทุนของการจำลองแบบ "bolt-on"
การเชื่อมต่อเลเยอร์จำลองแยกต่างหากเข้ากับ Bruno สามารถทำได้ แต่ต้นทุนจะปรากฏเมื่อเวลาผ่านไป:
- การเบี่ยงเบน (Drift) Spec ของคุณ, คำขอ Bruno ของคุณ, และคำจำกัดความการจำลองของคุณอยู่ในสามที่ที่แตกต่างกัน การเปลี่ยน endpoint คุณต้องอัปเดตทั้งสามอย่าง หรืออย่างใดอย่างหนึ่งอาจล้าสมัยโดยไม่รู้ตัว
- ค่าใช้จ่ายในการตั้งค่า (Setup tax) เพื่อนร่วมทีมใหม่ทุกคนต้องติดตั้งและกำหนดค่าเครื่องมือจำลองก่อนที่จะสามารถรันอะไรก็ได้ในเครื่อง
- การเขียนการตอบสนองด้วยตนเอง (Manual response writing) เซิร์ฟเวอร์ที่สร้างเองหมายถึงการเขียนเพย์โหลดตัวอย่างด้วยมือสำหรับทุกฟิลด์และทุกรหัสสถานะ
- ไม่มีข้อมูลที่สมจริง (No realistic data) สตับแบบคงที่ส่งคืน
"name": "string"แบบเดิมซ้ำๆ ซึ่งซ่อนข้อบกพร่องที่ปรากฏเฉพาะเมื่อมีการป้อนข้อมูลที่หลากหลาย
ไม่มีข้อเสียใดที่เป็นอันตรายถึงชีวิต แต่เป็นแรงเสียดทานที่สะสมมากขึ้นเมื่อ API เติบโตขึ้น สำหรับข้อมูลเพิ่มเติมเกี่ยวกับช่องว่างเหล่านี้ดูได้ที่ แพลตฟอร์ม API แบบครบวงจรทางเลือกของ Bruno ของเรา
สร้างเซิร์ฟเวอร์จำลองจาก OpenAPI spec ของคุณแทน
วิธีที่สะอาดกว่าคือการสร้างการจำลองจาก contract ที่คุณดูแลอยู่แล้ว Apidog ทำสิ่งนี้: นำเข้าหรือเขียน OpenAPI spec แล้วมันจะสร้างเซิร์ฟเวอร์จำลองที่ทำงานได้จากคำจำกัดความเดียวกับที่คุณใช้สำหรับการออกแบบ การทดสอบ และเอกสารประกอบ แหล่งข้อมูลความจริงเดียว ไม่ใช่สามแหล่ง
มีบางสิ่งที่ทำให้สิ่งนี้แตกต่างจากเครื่องมือ "bolt-on":
- การจำลองอัจฉริยะจาก Spec. Apidog อ่านชื่อฟิลด์และประเภท และส่งคืนข้อมูลที่เป็นไปได้ ดังนั้นฟิลด์
emailจะดูเหมือนอีเมล และฟิลด์created_atจะดูเหมือนวันที่ โดยไม่ต้องเขียนกฎใดๆ - การตอบสนองแบบไดนามิก. การตอบสนองจะถูกสร้างขึ้นจาก Schema ของคุณในแต่ละคำขอ ดังนั้นคุณจะได้รับข้อมูลที่หลากหลายแทนที่จะเป็นตัวอย่างที่คงที่ คุณสามารถเพิ่มกฎตามเงื่อนไขเมื่อคุณต้องการกรณีเฉพาะ
- การตั้งค่าแบบไม่ต้องเขียนโค้ด. คุณไม่ต้องเขียนหรือโฮสต์เซิร์ฟเวอร์แยกต่างหาก กำหนด endpoint ใน Spec แล้ว URL จำลองก็พร้อมใช้งาน
- ซิงค์อยู่เสมอ. อัปเดต Spec แล้วการจำลองก็จะอัปเดตตามไปด้วย เพราะใช้คำจำกัดความเดียวกัน
เนื่องจากการจำลอง, ไลบรารีคำขอ, และเอกสารประกอบมาจากโปรเจกต์เดียวกัน จึงไม่มีที่สามที่จะต้องรักษาให้สอดคล้องกัน หากเวิร์กโฟลว์ของคุณเน้น Git เป็นหลัก Spec ก็ยังคงสามารถเปรียบเทียบความแตกต่าง (diffable) และตรวจสอบได้ ซึ่งเข้ากันได้ดีกับ เวิร์กโฟลว์ API แบบ Git-native สำหรับข้อมูลเพิ่มเติมว่าการจำลองมีความสำคัญอย่างไร ดูได้ที่ กรณีการใช้งานการจำลอง API
วิธีเร่งรัด: จาก Spec สู่ Mock URL
นี่คือเวอร์ชันย่อของการตั้งค่าการจำลองจาก Spec ที่มีอยู่:
- นำเข้า Spec ของคุณ. นำไฟล์ OpenAPI (หรือ Swagger) ของคุณเข้ามา หรือชี้ Apidog ไปยัง URL ของ Spec Endpoint และ Schema ที่มีอยู่จะเข้ามาตามที่เป็นอยู่
- เปิด Endpoint. Endpoint ที่นำเข้าแต่ละรายการมี Schema ของตัวเองอยู่แล้ว ดังนั้นการจำลองจึงมีทุกสิ่งที่ต้องการ
- คัดลอก Mock URL. Apidog จะเปิดเผย Endpoint จำลองทั้งแบบโลคัลและคลาวด์โดยอัตโนมัติ ไม่ต้องมีการปรับใช้เซิร์ฟเวอร์
- ส่งคำขอ. เรียก Mock URL แล้วคุณจะได้รับ JSON ที่มีโครงสร้างตาม Schema กลับมา ซึ่งถูกสร้างขึ้นจาก Spec
- ปรับแต่งการตอบสนอง (ไม่บังคับ). เพิ่มกฎสำหรับรหัสสถานะเฉพาะหรือกรณีพิเศษ เช่น
429เมื่อคุณต้องการทดสอบเส้นทางใดเส้นทางหนึ่ง
คุณชี้ส่วนหน้า, โมบายล์บิลด์, หรือชุดทดสอบของคุณไปยัง Mock URL แล้วดำเนินการต่อในขณะที่แบ็กเอนด์ตามทัน
เมื่อวิธีแก้ไขปัญหาเฉพาะหน้าเพียงพอแล้ว
เพื่อให้เป็นธรรม บางครั้งคุณไม่จำเป็นต้องมีการจำลองที่ขับเคลื่อนด้วย Spec ยึดติดกับ Bruno บวกกับเครื่องมือภายนอกที่มีน้ำหนักเบาเมื่อ:
- คุณต้องการจำลองเพียงหนึ่งหรือสอง Endpoint เพื่อการทดสอบภายในอย่างรวดเร็ว
- ทีมของคุณมีความสุขกับการดูแลคอลเลกชันแบบไฟล์ของ Bruno และไม่ต้องการเปลี่ยนเครื่องมือ
- สตับแบบคงที่ก็เพียงพอแล้ว เพราะคุณไม่ได้ทดสอบข้อมูลที่หลากหลายหรือเส้นทางข้อผิดพลาดจำนวนมาก
- คุณใช้งาน Mockoon, WireMock, หรือ Prism อยู่แล้ว และแหล่งข้อมูลความจริงที่เพิ่มเข้ามาไม่ได้ทำให้คุณช้าลง
การแลกเปลี่ยนเป็นเรื่องจริง: เส้นทางที่น้ำหนักเบารักษาง่ายของ Bruno แต่ทำให้คุณต้องดูแลการจำลองแยกต่างหาก เส้นทางที่ขับเคลื่อนด้วย Spec ขจัดความเบี่ยงเบนนั้นด้วยต้นทุนของการนำแพลตฟอร์มที่กว้างขึ้นมาใช้ เลือกตามขนาดการเติบโตของ API ของคุณ
คำถามที่พบบ่อย
Bruno มีเซิร์ฟเวอร์จำลองในตัวหรือไม่?
ไม่มี. Bruno เป็นไคลเอนต์ API สำหรับส่งคำขอและรันการทดสอบ มันไม่มีเซิร์ฟเวอร์จำลองในตัว ดังนั้นในการจำลอง Endpoint คุณต้องใช้เครื่องมือภายนอกหรือเขียนเซิร์ฟเวอร์สตับของคุณเองแล้วชี้ Bruno ไปยังเซิร์ฟเวอร์นั้น
วิธีที่ง่ายที่สุดในการเพิ่มการจำลองลงในเวิร์กโฟลว์สไตล์ Bruno คืออะไร?
สร้างการจำลองจาก OpenAPI spec ของคุณแทนที่จะกำหนดแยกต่างหาก เครื่องมือเช่น Apidog อ่าน spec และสร้าง Mock URL ที่พร้อมใช้งาน เพื่อให้คุณรักษาแหล่งข้อมูลความจริงเดียวทั่วทั้งการออกแบบ การจำลอง การทดสอบ และเอกสารประกอบ แทนที่จะต้องดูแลคำจำกัดความการจำลองในที่ที่สอง
ฉันสามารถใช้ Bruno ต่อไปและเพิ่มเซิร์ฟเวอร์จำลองควบคู่ไปกับมันได้หรือไม่?
ได้. รันเครื่องมือจำลองภายนอกเช่น Mockoon, WireMock, หรือ Prism กำหนดการตอบสนองที่นั่น และชี้ Bruno ไปยัง URL นั้น มันทำงานได้ แต่ spec, คำขอ และข้อมูลจำลองของคุณจะอยู่ในที่ที่แยกกันและอาจเกิดการเบี่ยงเบนได้ ซึ่งเป็นเหตุผลหลักที่ทีมรวมเครื่องมือเข้าด้วยกัน
หากการดูแลเลเยอร์จำลองที่แยกต่างหากเริ่มมีค่าใช้จ่ายมากกว่าประโยชน์ที่ได้รับ ก็คุ้มค่าที่จะลองใช้การจำลองที่ขับเคลื่อนด้วย Spec นำเข้าไฟล์ OpenAPI ของคุณลงใน Apidog แล้วคุณจะมี Mock URL ที่ทำงานได้ภายในไม่กี่นาที โดยไม่ต้องโฮสต์เซิร์ฟเวอร์เพิ่มเติม