ทีมส่วนใหญ่รู้วิธีจำลอง API แต่มีน้อยทีมที่จะมีคำตอบที่ชัดเจนว่าเมื่อไหร่ที่มันช่วยได้จริง ๆ และเมื่อไหร่ที่มันแค่เพิ่มชั้นให้ต้องดูแลรักษา การจำลองที่คุณเลือกใช้ในเวลาที่เหมาะสมจะช่วยขจัดปัญหาคอขวดที่แท้จริงออกไป การจำลองที่คุณสร้างขึ้นจากความเคยชินจะกลายเป็นอีกสิ่งหนึ่งที่ห่างไกลจากความเป็นจริงและค่อย ๆ หลอกคุณ
บทความนี้จะข้ามวิธีการทำไปและเน้นที่ว่าควรทำเมื่อไหร่ แต่ละส่วนคือสถานการณ์ที่เป็นรูปธรรมที่การจำลองมีประโยชน์: การพัฒนาโดยอิงกับแบ็กเอนด์ที่ยังไม่เสร็จ, การทดสอบเส้นทางข้อผิดพลาด, การแทนที่บริการของบุคคลที่สามที่ไม่เสถียร, การนำเสนอเดโม, และการทำให้ CI มีเสถียรภาพ ควรอ่านบทความนี้เพื่อช่วยในการตัดสินใจ ไม่ใช่คู่มือ
การพัฒนาส่วนหน้าและส่วนหลังแบบคู่ขนาน
นี่คือกรณีคลาสสิก ทีมส่วนหน้าต้องการปลายทางที่ทีมส่วนหลังยังไม่ได้สร้าง หากไม่มีการจำลอง ส่วนหน้าจะต้องรอ หรือไม่ก็เขียนโค้ดโดยอิงจากการคาดเดาซึ่งจะพังเมื่อเชื่อมต่อกับบริการจริงครั้งแรก
การจำลองช่วยทำลายการพึ่งพากัน ทั้งสองทีมตกลงในสัญญาเป็นอันดับแรก โดยปกติแล้วจะอยู่ในรูปแบบเอกสาร OpenAPI ส่วนหน้าจะสร้างโดยอิงกับการจำลองที่สร้างขึ้นจากสัญญานั้น ในขณะที่ส่วนหลังจะนำไปใช้งานจริง เมื่อส่วนหลังเผยแพร่ ส่วนหน้าจะเปลี่ยน URL หลัก และหากทั้งสองฝ่ายเคารพสัญญา ก็จะไม่มีอะไรเปลี่ยนแปลงอีก
ข้อตกลงคือส่วนสำคัญ การจำลองที่ส่วนหน้าสร้างขึ้นเองนั้นเป็นเพียงการเข้ารหัสสมมติฐานของทีมเดียว การจำลองที่ได้มาจากข้อมูลจำเพาะที่แชร์กันช่วยให้ทั้งสองทีมสอดคล้องกัน ซึ่งเป็นหลักการเดียวกับ การทดสอบสัญญา API การจำลองเพื่อปลดล็อกการทำงานแบบคู่ขนาน แต่ต้องอยู่ภายใต้สัญญาที่ทั้งสองฝ่ายลงนามแล้วเท่านั้น
ผลตอบแทนจะเพิ่มขึ้นตลอดทั้งโครงการ ทีมส่วนหน้าที่ไม่เคยติดขัดเรื่องส่วนหลังสามารถส่งมอบฟีเจอร์ได้ตามกำหนดเวลาของตนเอง ทีมส่วนหลังที่ไม่ถูกรบกวนด้วยปลายทางที่ยังสร้างไม่เสร็จก็สามารถมุ่งเน้นได้ นักออกแบบและผู้จัดการผลิตภัณฑ์ได้รับเวอร์ชันที่สามารถคลิกได้เพื่อตอบสนองล่วงหน้าหลายสัปดาห์ สิ่งเหล่านี้ไม่จำเป็นต้องมีบริการจริงอยู่แล้ว ต้นทุนต่อเนื่องเพียงอย่างเดียวคือการทำให้การจำลองสอดคล้องกับสัญญาเมื่อสัญญามีการเปลี่ยนแปลง ซึ่งมีค่าใช้จ่ายถูกเมื่อการจำลองถูกสร้างขึ้นจากข้อมูลจำเพาะแทนที่จะเขียนด้วยมือ
การทดสอบเส้นทางข้อผิดพลาดที่คุณไม่สามารถกระตุ้นได้ตามต้องการ
API ที่ปกติจะส่งคืน 200 นั่นคือปัญหา โค้ดฝั่งไคลเอ็นต์ของคุณต้องจัดการกับ 429, 500, 503, เนื้อหาที่ผิดรูปแบบ และการหมดเวลา ซึ่งเซิร์ฟเวอร์ที่ทำงานได้ปกติจะไม่สร้างสิ่งเหล่านี้เมื่อการทดสอบของคุณร้องขอ
การจำลองสามารถสร้างสิ่งเหล่านี้ได้ตามคำสั่ง คุณกำหนดค่าให้มันส่งคืน 500 สำหรับคำขอหนึ่งครั้ง, 429 พร้อมเฮดเดอร์ Retry-After สำหรับอีกคำขอหนึ่ง, และเนื้อหาที่มาถึงหลังจากล่าช้าตามที่ตั้งใจไว้สำหรับคำขอที่สาม จากนั้นคุณยืนยันว่าตรรกะการลองใหม่, การถอยกลับ, และการจัดการการหมดเวลาของคุณทำงานได้ทั้งหมด
| ความล้มเหลวที่ต้องทดสอบ | การตั้งค่าการจำลอง | สิ่งที่พิสูจน์ |
|---|---|---|
| ข้อผิดพลาดของเซิร์ฟเวอร์ | ส่งคืน 500 |
ไคลเอ็นต์พยายามใหม่ จากนั้นลดระดับการทำงานลงอย่างนุ่มนวล |
| การจำกัดอัตรา | 429 พร้อม Retry-After |
ไคลเอ็นต์รอช่วงเวลาที่ถูกต้อง |
| เครือข่ายช้า | หน่วงเวลาตอบสนอง 5 วินาที | ไคลเอ็นต์หมดเวลาอย่างหมดจด |
| เพย์โหลดไม่ดี | ส่งคืน JSON ที่เสียหาย | ตัวแยกวิเคราะห์ล้มเหลวโดยไม่ขัดข้อง |
นี่คือกรณีการใช้งานที่ทีมส่วนใหญ่มักจะข้ามไปและเสียใจมากที่สุด การจัดการข้อผิดพลาดที่ไม่เคยถูกใช้งานคือการจัดการข้อผิดพลาดที่คุณไม่มี จับคู่การจำลองกับการ ยืนยัน API อย่างละเอียด เพื่อให้เส้นทางความล้มเหลวแต่ละเส้นทางได้รับการตรวจสอบ ไม่ใช่แค่สันนิษฐาน
มีข้อผิดพลาดประเภทที่สองที่ควรค่าแก่การจำลอง: การตอบกลับที่เป็น HTTP ที่ถูกต้องแต่ไม่ถูกต้องสำหรับโดเมนของคุณ การตอบกลับ 200 ที่มีราคาติดลบ, คำสั่งซื้อที่มีสถานะไม่อยู่ในรายการ enum ของคุณ, รายการแบบแบ่งหน้าที่มีเคอร์เซอร์ next ชี้ไปที่ไหนไม่ได้ เซิร์ฟเวอร์จริง หากถูกต้อง จะไม่มีทางส่งสิ่งเหล่านี้ การจำลองทำได้ และการป้อนข้อมูลที่ตั้งใจสร้างขึ้นมาผิดรูปแต่ดูเหมือนถูกต้องให้กับไคลเอ็นต์ของคุณคือวิธีที่คุณจะพบสมมติฐานที่โค้ดการแยกวิเคราะห์ของคุณทำขึ้นอย่างเงียบ ๆ
การแทนที่ API ของบุคคลที่สาม
การเรียกใช้ผู้ประมวลผลการชำระเงินจริง, บริการแผนที่, หรือ API การจัดส่งภายในชุดการทดสอบของคุณนั้นช้า บางครั้งมีค่าใช้จ่ายต่อการเรียก และขึ้นอยู่กับบริการที่คุณไม่ได้ควบคุม หาก sandbox ของพวกเขาไม่ทำงาน ชุดการทดสอบของคุณก็จะไม่ทำงาน
จำลองบุคคลที่สาม คุณบันทึกการตอบกลับจริงของมันเพียงครั้งเดียว หรือสร้างการจำลองจาก schema ที่เผยแพร่ จากนั้นรันการทดสอบของคุณกับสิ่งจำลอง การทดสอบจะรวดเร็ว, ฟรี, และคาดการณ์ได้ นอกจากนี้ยังคงทำงานได้แม้ผู้ให้บริการมีปัญหาขัดข้อง
มีค่าใช้จ่ายในการบำรุงรักษา บุคคลที่สามสามารถเปลี่ยนแปลง API ของตนได้โดยไม่บอกคุณ และการจำลองของคุณจะไม่ทราบ วิธีแก้ไขคือการสร้างงานตามกำหนดเวลาเล็ก ๆ ที่เรียกใช้บริการจริงและยืนยันว่าการตอบกลับยังคงตรงกับโครงสร้างของการจำลองของคุณ การตรวจสอบสัญญาเป็นเพียงจุดเดียวที่คุณจะแตะต้องบุคคลที่สามจริง ๆ และมันจะจับความคลาดเคลื่อนได้ก่อนที่ผู้ใช้ของคุณจะพบเจอ นอกจากนี้ยังควรสมัครรับ changelog ของผู้ให้บริการ เพื่อให้การเปลี่ยนแปลงที่วางแผนไว้มาถึงคุณก่อนที่การทดสอบสัญญาจะล้มเหลว
การขับเคลื่อนเดโมและต้นแบบ
การนำเสนอเดโมที่เรียกใช้บริการจริงต่อหน้าลูกค้าคือการเสี่ยงโชค การสืบค้นที่ช้า, ชุดผลลัพธ์ที่ว่างเปล่า, หรือการขัดข้องที่ไม่คาดฝัน จะเปลี่ยนการนำเสนอที่สวยงามให้กลายเป็นการขอโทษ
การจำลองทำให้เดโมสามารถคาดการณ์ผลลัพธ์ได้ คุณเขียนสคริปต์ข้อมูลที่เดโมต้องการอย่างแม่นยำ: คำสั่งซื้อที่จัดส่งตรงเวลา, แดชบอร์ดที่มีตัวเลขที่ดูดี, การค้นหาที่ให้ผลลัพธ์ที่ชัดเจน สิ่งเดียวกันนี้ใช้ได้กับต้นแบบ คุณสามารถตรวจสอบความถูกต้องของขั้นตอน UI หรือนำเสนอคุณสมบัติได้นานก่อนที่จะมีแบ็กเอนด์ใด ๆ เนื่องจากสิ่งจำลองจะให้การตอบสนองทุกอย่างที่ต้นแบบคาดหวัง
จุดสำคัญในที่นี้ไม่ใช่การทดสอบ แต่คือการควบคุม คุณเป็นผู้ตัดสินใจว่าผู้ชมจะเห็นอะไร และไม่มีสิ่งภายนอกใด ๆ สามารถทำให้มันเสียได้ สำหรับงานในระยะเริ่มต้น การจำลองมักจะเป็นวิธีที่เร็วที่สุดในการนำสิ่งที่สามารถคลิกได้ไปแสดงให้ผู้คนเห็น เครื่องมือที่เปรียบเทียบในหมวดหมู่นี้ถูกกล่าวถึงในบทความเกี่ยวกับ เครื่องมือจำลอง API ออนไลน์
การจำลองต้นแบบยังทำหน้าที่เป็นเอกสารการออกแบบอีกด้วย เมื่อการจำลองส่งคืนรูปแบบที่ API จริงจะให้บริการ โค้ดส่วนหน้าที่คุณเขียนโดยอิงจากมันก็คือโค้ดจริง ไม่ใช่โครงสร้างชั่วคราวที่ทิ้งไป หากแบ็กเอนด์ในภายหลังเคารพสัญญาเดียวกัน ต้นแบบก็จะกลายเป็นผลิตภัณฑ์โดยมีการเปลี่ยนแค่ URL พื้นฐานเท่านั้น นั่นคือความแตกต่างระหว่างการจำลองที่ใช้เป็นไม้ค้ำยันกับการจำลองที่ใช้เป็นจุดเริ่มต้น
การทำให้ CI รวดเร็วและเสถียร
ชุดการทดสอบที่เรียกใช้บริการภายนอกใน CI จะรับเอาปัญหาทุกอย่างที่บริการเหล่านั้นมีมาด้วย การขัดข้องของเครือข่าย, การจำกัดอัตรา, ข้อมูล staging ที่ถูกแชร์ซึ่งบิลด์อื่นเพิ่งแก้ไข: แต่ละอย่างกลายเป็นความล้มเหลวที่ไม่เสถียรซึ่งไม่เกี่ยวข้องกับโค้ดที่กำลังตรวจสอบ
การทดสอบที่ไม่เสถียรทำให้คนเรียนรู้ที่จะเพิกเฉยต่อความล้มเหลว ซึ่งขัดต่อวัตถุประสงค์ของ CI การจำลองการพึ่งพาภายนอกทำให้ชุดการทดสอบเป็นแบบปิด (hermetic) ทุกครั้งที่รันจะเริ่มต้นจากสถานะที่ทราบเหมือนกัน ทำงานเสร็จเร็วขึ้นเพราะไม่มีการเดินทางของเครือข่าย และจะล้มเหลวเมื่อโค้ดเสียจริง ๆ เท่านั้น
ให้มีข้อยกเว้นหนึ่งข้อ เรียกใช้การทดสอบสัญญาแบบบาง ๆ กับ API จริงตามกำหนดเวลา แยกต่างหากจากชุดการทดสอบต่อการคอมมิต สิ่งเหล่านั้นยืนยันว่าการจำลองยังคงตรงกับผลิตภัณฑ์จริง ชุดการทดสอบต่อการคอมมิตยังคงรวดเร็วและใช้การจำลองอยู่; งานตามกำหนดเวลาจะจับความคลาดเคลื่อน การแยกนี้เป็นหัวใจสำคัญของ ไปป์ไลน์การทดสอบ CI/CD ที่แข็งแรง
ความเร็วที่เพิ่มขึ้นไม่ใช่ความสะดวกเล็กน้อย ชุดการทดสอบที่ลดลงจากสิบสองนาทีเหลือเก้าสิบวินาทีเปลี่ยนวิธีการทำงานของทีม นักพัฒนาจะรันมันก่อนทุกการพุชแทนที่จะคาดหวัง ผู้ตรวจสอบจะเห็นผลลัพธ์ในเวลาที่ใช้ในการอ่านความแตกต่าง ชุดการทดสอบที่รวดเร็วและเป็นแบบปิดคือสิ่งที่ผู้คนไว้วางใจจริง ๆ และความไว้วางใจคือนี่คือผลตอบแทนจากการลงทุนทั้งหมดของการทดสอบอัตโนมัติ
เมื่อไม่ควรใช้การจำลอง
การจำลองมีรูปแบบความล้มเหลว: การจำลองที่ไม่ตรงกับความเป็นจริงอีกต่อไป การทดสอบยังคงผ่านสีเขียวในขณะที่ระบบจริงขัดข้อง เพราะพวกเขากำลังตรวจสอบสิ่งที่ไม่ใช่ความจริง
อย่าจำลองเมื่อสิ่งที่กำลังทดสอบคือการผสานรวมกันเอง การทดสอบสัญญาและการตรวจสอบแบบ end-to-end มีไว้เพื่อยืนยันขอบเขตจริง ดังนั้นการจำลองสิ่งเหล่านี้จะทำให้เหตุผลในการมีอยู่ของพวกมันหายไป อย่าจำลองการพึ่งพาที่คุณไม่เคยตรวจสอบกับของจริง เพราะการจำลองที่ไม่ได้รับการยืนยันจะคลาดเคลื่อน และอย่าเลือกใช้การจำลองเมื่อบริการจริงรวดเร็ว ฟรี และเชื่อถือได้ในสภาพแวดล้อมการทดสอบของคุณ; การจำลองจะเป็นแค่ภาระเพิ่มเติมเท่านั้น
กฎง่ายๆ คือ: จำลองเพื่อความเร็ว การแยกตัว และการควบคุม และรักษากลุ่มการทดสอบเล็กๆ ที่ซื่อสัตย์ที่สัมผัสกับความเป็นจริงเพื่อยืนยันว่าการจำลองยังคงถูกต้อง หากคุณต้องการให้การจำลองและการตรวจสอบสัญญาอยู่ในที่เดียวกัน Apidog จะสร้างการจำลองจากการออกแบบ API ของคุณและรันการทดสอบทั้งกับสิ่งจำลองและปลายทางจริง ในการตั้งค่านี้ ดาวน์โหลด Apidog และเริ่มต้นจากข้อมูลจำเพาะที่มีอยู่ของคุณ สำหรับพื้นฐานแนวคิด โปรดดูว่า mock API คืออะไร
คำถามที่พบบ่อย
ฉันควรจำลอง API แทนการเรียกใช้ API จริงเมื่อใด
จำลองเมื่อคุณต้องการความเร็ว การแยกตัว หรือการควบคุม: การพัฒนาแบบคู่ขนานโดยอิงจากแบ็กเอนด์ที่ยังไม่เสร็จ, การทดสอบเส้นทางข้อผิดพลาดที่เซิร์ฟเวอร์จริงจะไม่สร้างขึ้น, การแทนที่บริการของบุคคลที่สามที่ช้าหรือมีค่าใช้จ่าย, การนำเสนอเดโม, และการทำให้ CI มีเสถียรภาพ เรียกใช้ API จริงสำหรับการทดสอบสัญญาและการทดสอบแบบ end-to-end
การจำลองแทนที่การทดสอบการผสานรวมหรือไม่
ไม่ การจำลองมีไว้สำหรับการทดสอบหน่วยและการทดสอบส่วนประกอบที่คุณกำลังตรวจสอบโค้ดของคุณเอง การทดสอบการผสานรวมและสัญญาจะต้องเข้าถึงขอบเขตจริง เนื่องจากหน้าที่ของมันคือการยืนยันว่าบริการจริงตรงกับสัญญา การจำลองสิ่งเหล่านั้นจะทำให้วัตถุประสงค์ของมันหายไป
ฉันจะป้องกันไม่ให้การจำลองล้าสมัยได้อย่างไร
สร้างการจำลองจาก schema ที่แชร์กัน โดยเฉพาะ OpenAPI เพื่อให้การเปลี่ยนแปลงสัญญาอัปเดตมัน จากนั้นเรียกใช้การทดสอบสัญญาตามกำหนดเวลาเทียบกับ API จริงเพื่อยืนยันว่าการตอบกลับแบบสดนั้นยังคงตรงกับ schema นั้น ความคลาดเคลื่อนจะถูกจับได้ก่อนที่จะไปถึงผู้ใช้
ฉันสามารถจำลอง API ของบุคคลที่สามที่ฉันไม่ได้ควบคุมได้หรือไม่
ได้ และนี่เป็นหนึ่งในกรณีการใช้งานที่แข็งแกร่งที่สุด บันทึกการตอบกลับจริงของบุคคลที่สาม หรือสร้างการจำลองจาก schema ที่เผยแพร่ จากนั้นทดสอบกับสิ่งจำลองเพื่อความเร็วและความน่าเชื่อถือ เพิ่มการตรวจสอบตามกำหนดเวลาเทียบกับบริการจริงเพื่อให้คุณสังเกตเห็นเมื่อผู้ให้บริการเปลี่ยนแปลง API ของตน
การจำลองมีประโยชน์สำหรับการนำเสนอเดโมและต้นแบบหรือไม่
มีประโยชน์มาก การจำลองทำให้เดโมสามารถคาดการณ์ผลลัพธ์ได้โดยการเขียนสคริปต์ข้อมูลที่คุณต้องการให้ผู้ชมเห็นอย่างแม่นยำ โดยไม่มีความเสี่ยงจากการขัดข้องแบบสดหรือข้อมูลที่ไม่เป็นที่ต้องการ สำหรับต้นแบบ การจำลองช่วยให้คุณสามารถสร้างและตรวจสอบความถูกต้องของขั้นตอน UI ได้ก่อนที่จะมีแบ็กเอนด์ใดๆ