Mock API คืออะไร? อธิบายเข้าใจง่าย

Mock API คือ API ปลอมที่ทำงานเหมือนของจริง มันรับคำขอแบบเดียวกัน คืนค่าการตอบกลับในรูปแบบเดียวกัน และอยู่ที่ URL ที่คุณสามารถเรียกได้ แต่เบื้องหลัง URL นั้นไม่มีฐานข้อมูลจริง ไม่มีตรรกะทางธุรกิจ และไม่มีบริการจริง การตอบกลับเป็นสิ่งที่คุณกำหนดไว้ล่วงหน้า

ฟังดูเป็นเรื่องง่ายๆ และแนวคิดก็เป็นเช่นนั้น คุณค่ามาจากการที่มันช่วยให้คุณทำอะไรได้บ้าง: สร้างและทดสอบกับอินเทอร์เฟซก่อนที่สิ่งเบื้องหลังจะเกิดขึ้น หรือในขณะที่ของจริงช้าเกินไป แพงเกินไป หรือไม่น่าเชื่อถือเกินกว่าจะเรียกใช้ คำอธิบายนี้กำหนดคำศัพท์ได้อย่างแม่นยำ แยก mock ออกจากสิ่งที่มักถูกเข้าใจผิด และวางหลักความแตกต่างระหว่าง static กับ dynamic ที่เป็นตัวกำหนดว่า mock ทำงานอย่างไร

Mock API คืออะไรกันแน่

กล่าวโดยสรุปคือ Mock API เป็นแผนที่การจับคู่คำขอกับการตอบกลับ เมื่อมีคำขอเข้ามา Mock จะจับคู่กับกฎที่คุณกำหนด เลือกการตอบกลับ และส่งกลับไป ไม่มีการคำนวณใดๆ ในระหว่างนั้น เว้นแต่คุณจะร้องขอ

Mock มีสามส่วน ส่วนแรกคืออินเทอร์เฟซ: เส้นทาง, เมธอด และพารามิเตอร์ที่ยอมรับ ซึ่งควรตรงกับ API จริงทุกประการ ส่วนที่สองคือการกำหนดการตอบกลับ: เนื้อหา, รหัสสถานะ และส่วนหัวที่ส่งคืน และส่วนที่สามคือตรรกะการจับคู่: วิธีที่ mock ตัดสินใจว่าจะส่งการตอบกลับใดสำหรับคำขอที่กำหนด ตั้งแต่การจับคู่พาธแบบง่ายไปจนถึงกฎที่แยกตามพารามิเตอร์การสอบถามหรือส่วนหัว

เนื่องจากอินเทอร์เฟซตรงกับ API จริง โค้ดที่เรียกใช้ mock จึงไม่รู้ว่ามันเป็นของปลอม เพียงแค่เปลี่ยน Base URL และไคลเอ็นต์เดียวกันก็สามารถสื่อสารกับบริการจริงได้ ความสามารถในการสับเปลี่ยนนี้คือหัวใจสำคัญ สำหรับคำแนะนำเชิงปฏิบัติในการสร้าง mock โปรดดูคู่มือนี้เกี่ยวกับการ สร้าง mock API สำหรับการทดสอบ

การทำความเข้าใจอย่างแม่นยำว่า Mock API ไม่ใช่อะไรนั้นมีประโยชน์ มันไม่ใช่แคช เพราะแคชจัดเก็บการตอบกลับจริง แต่ mock สร้างการตอบกลับขึ้นมาเอง มันไม่ใช่แซนด์บ็อกซ์ เพราะแซนด์บ็อกซ์ของผู้จำหน่ายรันตรรกะจริงที่เรียบง่าย แต่ mock ไม่ได้รันตรรกะใดๆ เลย และมันไม่ใช่ staging environment เพราะ staging คือการปรับใช้ระบบจริงแบบสมบูรณ์ Mock มีน้ำหนักเบากว่าทั้งสามอย่าง: มันเป็นเพียงหน้าต่างของ API ที่มีคำตอบที่กำหนดไว้ล่วงหน้าอยู่เบื้องหลัง และไม่มีอะไรอื่นอีก

Mock เทียบกับ Stub

ผู้คนใช้คำว่า "mock" และ "stub" สลับกันไปมา แต่ในการทดสอบ คำเหล่านี้มีความหมายต่างกัน

Stub เป็นแนวคิดที่ง่ายกว่า มันคืนค่าคำตอบที่กำหนดไว้ล่วงหน้าสำหรับการเรียก และไม่มีอะไรมากไปกว่านั้น ถ้าขอข้อมูลผู้ใช้ มันจะคืนค่าผู้ใช้ที่กำหนดไว้ Stub ไม่มีส่วนเกี่ยวข้องกับวิธีการที่ถูกเรียกใช้

Mock ในความหมายของการทดสอบอย่างเคร่งครัด ยังตรวจสอบการโต้ตอบด้วย มันสามารถยืนยันได้ว่าถูกเรียกใช้หรือไม่ กี่ครั้ง และด้วยอาร์กิวเมนต์ใด Mock สามารถทำให้การทดสอบของคุณล้มเหลวได้หากการเรียกใช้ผิดพลาด ไม่ใช่แค่เพียงการให้ค่าเท่านั้น

ในการทำงาน API ทั่วไป เส้นแบ่งยังไม่ชัดเจน และ “mock API” มักจะครอบคลุมทั้งสองอย่าง ข้อคิดที่มีประโยชน์: stub ตอบ, mock ตอบและเฝ้าดู เมื่อการทดสอบของคุณสนใจแค่ข้อมูลที่โค้ดของคุณได้รับ การตอบกลับแบบ stub ก็เพียงพอแล้ว เมื่อมันสนใจว่าโค้ดของคุณเรียกใช้ถูกต้องตามวิธีที่ถูกต้องหรือไม่ คุณต้องการการตรวจสอบที่ mock แท้ๆ เพิ่มเข้ามา สำหรับคำศัพท์ที่กว้างขึ้น โปรดดูความแตกต่างระหว่าง การตรวจสอบความถูกต้องและการยืนยัน

มีอีกสองคำที่เกี่ยวข้องใกล้เคียงกัน Fake คือการนำไปใช้งานที่ทำงานได้แต่เรียบง่าย เช่น ฐานข้อมูลในหน่วยความจำที่ใช้แทนฐานข้อมูลจริง มันมีตรรกะ แต่มีน้อยกว่า Spy จะห่อหุ้มออบเจกต์จริงและบันทึกว่ามันถูกเรียกใช้อย่างไรโดยไม่เปลี่ยนแปลงพฤติกรรมของมัน Mock API ตามที่ใช้ในการพัฒนา API จะใกล้เคียงกับ stub ที่มีการตรวจสอบเพิ่มเติม ซึ่งให้บริการผ่าน HTTP ที่ URL จริง คุณไม่จำเป็นต้องเคร่งครัดเรื่องคำศัพท์ แต่การรู้ขอบเขตจะช่วยให้คุณอ่านเอกสารการทดสอบได้โดยไม่สับสน

Mock API เทียบกับเซิร์ฟเวอร์จริง

เซิร์ฟเวอร์จริงและ mock server สามารถอยู่ที่ URL เดียวกันและคืนค่า JSON เดียวกันได้ ดังนั้นความแตกต่างคือสิ่งที่เกิดขึ้นเบื้องหลัง endpoint

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

Mock server จะบอกคุณเฉพาะสิ่งที่คุณบอกมันเท่านั้น มันรวดเร็ว ปราศจากผลข้างเคียง และคาดการณ์ได้สมบูรณ์แบบ ซึ่งทำให้เหมาะสำหรับการพัฒนาและการทดสอบส่วนใหญ่ แต่ mock อาจผิดพลาดและไม่รู้ตัว เพราะมันไม่ได้รันตรรกะจริง นั่นคือเหตุผลที่คุณยังคงต้องทำการทดสอบบางส่วนบนเซิร์ฟเวอร์จริง การแลกเปลี่ยนนี้มีอธิบายอย่างละเอียดในบทความ mock server เทียบกับเซิร์ฟเวอร์จริง

Mock แบบ Static และ Dynamic

Mock ส่งคืนการตอบกลับด้วยวิธีใดวิธีหนึ่งจากสองวิธี และการเลือกจะส่งผลต่อความรู้สึกในการใช้งาน mock

Static mock จะคืนค่าเพย์โหลดที่คงที่ คุณเขียน JSON ที่แน่นอนเพียงครั้งเดียว และทุกคำขอที่ตรงกันจะได้รับเนื้อหาเดียวกันกลับไป Static mock สามารถคาดเดาได้ ทำให้ง่ายต่อการตรวจสอบ จุดอ่อนของมันคือความสมจริง: เพย์โหลดที่ฮาร์ดโค้ดเพียงอย่างเดียวจะไม่เปิดเผยข้อบกพร่องในโค้ดที่เสียหายเมื่อเจอสตริงยาวๆ, อาร์เรย์ว่างเปล่า หรือค่า null ที่ไม่คาดคิด

Dynamic mock สร้างการตอบกลับต่อคำขอแต่ละครั้ง แทนที่จะเป็น "id": "user_1001" ที่คงที่ มันจะสร้าง UUID ใหม่ทุกครั้งที่เรียก แทนที่จะเป็นชื่อเดียว มันจะคืนค่าชื่อที่สมจริงแตกต่างกันไปในแต่ละครั้ง Dynamic mock มักจะขับเคลื่อนสิ่งนี้ด้วยไวยากรณ์การสร้างข้อมูล เช่น Faker.js ดังนั้นฟิลด์ชื่อ email จะให้ค่าอีเมล และ created_at จะให้ค่าวันที่ พวกมันมีความสมจริงมากกว่าและดีกว่าในการเปิดเผย edge cases แต่ก็แลกมาด้วยความยากลำบากในการยืนยันผลลัพธ์ที่แน่นอน

ทีมส่วนใหญ่ใช้ทั้งสองแบบ Static mock ใช้สำหรับการทดสอบหน่วยที่เน้นการยืนยัน ซึ่งคุณต้องการค่าที่ทราบเพียงค่าเดียว Dynamic mock ใช้สำหรับการพัฒนา, การสาธิต และการครอบคลุมแบบ fuzz-style ที่ความหลากหลายมีความสำคัญมากกว่าคำตอบที่คงที่

Dynamic mock ยังสามารถเป็นแบบมีเงื่อนไขได้ ซึ่งเป็นขั้นที่ก้าวหน้ากว่าการสร้างแบบธรรมดา Conditional mock จะแยกตามคำขอ: คำขอสำหรับ /orders/404 จะคืนค่า 404, คำขอที่มีโทเค็นที่ไม่ถูกต้องจะคืนค่า 401, และอื่นๆ ทั้งหมดจะคืนค่า 200 ปกติ Endpoint ของ mock เพียงหนึ่งเดียวก็จะครอบคลุมทั้งกรณี happy path และหลายกรณีที่ล้มเหลวในคราวเดียว นี่คือสิ่งที่ทำให้ mock มีประโยชน์อย่างแท้จริงสำหรับการทดสอบ เพราะมันสามารถจำลองการตอบกลับข้อผิดพลาดที่เซิร์ฟเวอร์จริงที่ทำงานปกติจะไม่สร้างให้ตามต้องการ

Mock API มีบทบาทอย่างไรในการพัฒนา

Mock API มีประโยชน์ในสามจุด ในช่วงเริ่มต้น ช่วยให้ทีมฟรอนต์เอนด์และแบ็กเอนด์ตกลงกันในสัญญาและพัฒนาไปพร้อมกันได้ โดยที่ไม่มีฝ่ายใดต้องรออีกฝ่าย ระหว่างการทดสอบ มันจะแยกโค้ดของคุณออกจากความไม่เสถียรของเครือข่าย และช่วยให้คุณสามารถกระตุ้นการตอบกลับข้อผิดพลาดที่เซิร์ฟเวอร์จริงจะไม่สร้างให้ตามต้องการ และสำหรับการสาธิตและต้นแบบ มันจะให้ข้อมูลที่ควบคุมได้และคาดการณ์ได้ โดยไม่มีการพึ่งพาข้อมูลจริงที่อาจล้มเหลวระหว่างการนำเสนอ สถานการณ์เหล่านี้มีการสำรวจเพิ่มเติมในคู่มือนี้เกี่ยวกับ กรณีการใช้งาน Mocking API

ความเสี่ยงที่เกิดขึ้นซ้ำๆ คือความคลาดเคลื่อน (drift) Mock คือสแนปช็อตของอินเทอร์เฟซ และอินเทอร์เฟซก็เปลี่ยนแปลงได้ เมื่อ API จริงเพิ่มฟิลด์หรือเปลี่ยนชื่อ Mock ที่ไม่ได้เชื่อมต่อจะยังคงส่งรูปแบบเก่า และการทดสอบของคุณจะผ่านกับสัญญาที่ไม่มีอยู่อีกต่อไป

วิธีแก้คือการถือว่า mock เป็นสิ่งที่ได้มา ไม่ใช่สิ่งที่สร้างขึ้นเอง สร้างมันจาก Schema เดียวกันกับที่ API จริงเผยแพร่ เพื่อให้การเปลี่ยนแปลงสัญญาจะสร้าง mock ขึ้นมาใหม่ mock ที่คุณพิมพ์ด้วยมือคือสำเนาที่จะเริ่มล้าสมัยทันที mock ที่สร้างจากสเปกจะเป็นสแนปช็อตปัจจุบันเสมอ ความแตกต่างนี้อาจไม่ปรากฏในวันแรก แต่เป็นตัวตัดสินว่า mock ยังคงน่าเชื่อถืออยู่หรือไม่หลังจากหกเดือน Apidog ทำงานในลักษณะนี้: คุณออกแบบ API เพียงครั้งเดียว และ mock endpoint จะถูกสร้างขึ้นจากการออกแบบนั้นพร้อมข้อมูลที่สมจริงซึ่งอนุมานจากชื่อฟิลด์ Mock, เอกสารประกอบ และ การทดสอบสัญญา API ทั้งหมดอ่านจากแหล่งเดียว จึงคงความสอดคล้องกัน หากต้องการดูขั้นตอนการออกแบบสู่ mock แบบครบวงจร ดาวน์โหลด Apidog

คำถามที่พบบ่อย

Mock API คืออะไรในความหมายง่ายๆ?

Mock API คือ API ปลอมที่เลียนแบบ API จริง มันเปิดเผยเส้นทางเดียวกันและคืนค่าการตอบกลับในรูปแบบเดียวกัน แต่ไม่มีตรรกะหรือฐานข้อมูลจริงอยู่เบื้องหลัง การตอบกลับถูกกำหนดไว้ล่วงหน้า ซึ่งช่วยให้คุณสามารถสร้างและทดสอบกับอินเทอร์เฟซได้ก่อนที่บริการจริงจะพร้อมใช้งาน

อะไรคือความแตกต่างระหว่าง Mock กับ Stub?

Stub คืนค่าการตอบกลับที่กำหนดไว้ล่วงหน้าและไม่มีอะไรมากไปกว่านั้น Mock ในความหมายของการทดสอบอย่างเคร่งครัด ยังตรวจสอบการโต้ตอบด้วย ดังนั้นมันจึงสามารถตรวจสอบได้ว่าถูกเรียกใช้จำนวนครั้งที่ถูกต้องด้วยอาร์กิวเมนต์ที่ถูกต้องหรือไม่ Stub ตอบ; mock ตอบและเฝ้าดู

Mock API แตกต่างจากเซิร์ฟเวอร์จริงอย่างไร?

Mock คืนค่าการตอบกลับที่กำหนดไว้ล่วงหน้าโดยไม่มีการคำนวณจริง ดังนั้นจึงรวดเร็ว คาดการณ์ได้ และไม่มีผลข้างเคียง เซิร์ฟเวอร์จริงรันตรรกะจริงกับฐานข้อมูลจริง ดังนั้นจึงช้ากว่าและมีสถานะ แต่พิสูจน์ว่าระบบทำงานได้จริง ใช้ mock สำหรับการพัฒนา และใช้เซิร์ฟเวอร์จริงสำหรับการทดสอบสัญญาและ end-to-end

ควรใช้ Static mock หรือ Dynamic mock?

ใช้ static mock เมื่อคุณต้องการค่าที่คาดการณ์ได้หนึ่งค่าเพื่อยืนยัน ซึ่งเหมาะกับการทดสอบหน่วย ใช้ dynamic mock เมื่อคุณต้องการข้อมูลที่สมจริงและหลากหลายที่สามารถจับ edge cases ได้ ซึ่งเหมาะกับการพัฒนาและการสาธิต หลายทีมใช้ทั้งสองแบบ

จะทำอย่างไรไม่ให้ Mock API ไม่ถูกต้อง?

สร้าง mock จาก schema เดียวกันกับที่ API จริงเผยแพร่ แทนที่จะเขียนด้วยมือ เมื่อสัญญามีการเปลี่ยนแปลง mock จะถูกสร้างขึ้นใหม่ การสนับสนุนด้วยการทดสอบสัญญาที่กำหนดเวลาไว้กับ API จริงจะช่วยตรวจจับความคลาดเคลื่อนที่เหลืออยู่ได้ตั้งแต่เนิ่นๆ