จำลอง Timeout เมื่อเซิร์ฟเวอร์เงียบหายและไคลเอนต์พยายามซ้ำ
การทดสอบ API Mock ที่ส่งแค่ 200 OK ไม่เพียงพอในการจับบั๊ก timeout, การ retry, และ idempotency เรียนรู้วิธีจำลองเซิร์ฟเวอร์ที่เงียบหายเพื่อทดสอบความทนทานของโค้ด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การจำลองค่าสถานะ 200 OK อย่างเดียวไม่สามารถทดสอบพฤติกรรมเมื่อเซิร์ฟเวอร์ไม่ตอบสนองได้
- ต้องทดสอบทั้งกรณีเซิร์ฟเวอร์ตอบช้าหลังไคลเอนต์ยกเลิกคำขอ และกรณีเซิร์ฟเวอร์นิ่งเงียบไม่ส่งข้อมูล
- การทดสอบการ Retry ต้องตรวจสอบจำนวนครั้ง ระยะเวลาหน่วง และการส่ง Idempotency Key ซ้ำทุกครั้ง
- ควรแยก Timeout ระหว่างการเชื่อมต่อ (Connection Timeout) กับการรอข้อมูล (Read Timeout) ออกจากกัน
การใช้ Mock ที่คืนค่า 200 OK ตลอดเวลาไม่สามารถทดสอบจุดอ่อนที่แท้จริงของไคลเอนต์ได้ เนื่องจากปัญหาที่พบบ่อยในระบบจริงคือสถานการณ์ที่เซิร์ฟเวอร์ไม่ตอบสนองเลย พฤติกรรมอย่าง Timeout, การส่งคำขอซ้ำ (Retries), ระบบหน่วงเวลา (Backoff) และการจัดการ Idempotency ล้วนทำงานฝั่งไคลเอนต์ และจะถูกกระตุ้นก็ต่อเมื่อตัวจำลองจงใจหยุดชะงักหรือหน่วงเวลาเท่านั้น
หากนักพัฒนาไม่ได้จำลองกรณีไม่มีการตอบสนอง เมื่อเซิร์ฟเวอร์ต้นทางเกิดอาการค้างเป็นครั้งแรก ไคลเอนต์อาจเลือกที่จะรออย่างไร้กำหนด ส่งคำขอซ้ำทันทีจนเซิร์ฟเวอร์ล่ม หรือสร้างคำสั่งซื้อที่ซ้ำซ้อนขึ้นมา แนวทางปฏิบัติคือการสร้าง Stub สองแบบ แบบแรกคือการถือการเชื่อมต่อค้างไว้เกินกว่ากำหนดเวลา Timeout ของไคลเอนต์ และแบบที่สองคือการตอบกลับช้าแต่สำเร็จ เพื่อนำผลลัพธ์มาเปรียบเทียบความแตกต่าง
การปะปนกันระหว่างกรณีที่เซิร์ฟเวอร์ตอบกลับมาช้าหลังจากที่ไคลเอนต์ยกเลิกคำขอไปแล้ว ถือเป็นข้อผิดพลาดที่พบบ่อย หากนำข้อมูล 200 ที่มาถึงช้าไปบันทึกทับสถานะแอปพลิเคชัน จะเกิดบั๊กคลาสสิกประเภทคำขอหมดเวลาแต่ข้อมูลยังคงถูกบันทึกในระบบ โมกเซิร์ฟเวอร์ส่วนใหญ่รองรับคำสั่งกำหนดเวลาหน่วง (Delay Directive) โดยมีเงื่อนไขว่าระยะเวลาหน่วงต้องมากกว่าค่า Timeout ของไคลเอนต์เพื่อให้กระบวนการยกเลิกคำขอทำงานจริง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในทางวิศวกรรมซอฟต์แวร์ การทำความเข้าใจความแตกต่างระหว่าง Connection Timeout และ Read Timeout มีความสำคัญอย่างยิ่งต่อการออกแบบระบบกระจายศูนย์ (Distributed Systems) การที่ระบบไม่สามารถเชื่อมต่อได้เลย (เช่น ปิดพอร์ตหรือโฮสต์ล่ม) มีความเสี่ยงต่ำกว่าการหมดเวลารออ่านข้อมูล ซึ่งคำขอนั้นอาจถูกประมวลผลสำเร็จไปแล้วบนฝั่งเซิร์ฟเวอร์ การใช้กลยุทธ์ Retry แบบเหมาเข่งจึงอาจนำไปสู่ความเสียหายร้ายแรงหากปราศจากการแนบ Idempotency Key ทุกครั้งที่มีการส่งข้อมูลซ้ำ
การทดสอบการ Retry จำเป็นต้องตรวจสอบ 3 ประเด็นสำคัญ ได้แก่ จำนวนครั้งที่พยายามส่ง ระยะห่างระหว่างเวลา และการแนบ Idempotency Key ตัวเดิมในทุกความพยายาม หากไม่มีคีย์ดังกล่าว การส่งคำขอซ้ำไปยังเซิร์ฟเวอร์จริงอาจทำให้ผู้ใช้งานถูกตัดเงินสองครั้ง นอกจากนี้ การตรวจสอบจังหวะการหน่วงเวลาใน Unit Test ควรใช้วิธีฉีดตัวนับเวลา (Clock or Scheduler) แทนการหน่วงเวลาด้วยมิลลิวินาทีจริง เพื่อให้ชุดทดสอบทำงานได้อย่างรวดเร็วและแม่นยำ
ความแตกต่างอีกประการหนึ่งที่ควรแยกทดสอบคือ Connection Timeout ซึ่งเกิดขึ้นเมื่อการทำ TCP Handshake ไม่สำเร็จ กับ Read Timeout ที่เกิดขึ้นหลังเชื่อมต่อได้แต่ไม่มีข้อมูลส่งกลับมา การใช้ Mock ที่จงใจหน่วงเวลาจะครอบคลุมเฉพาะกรณีหลัง ส่วนกรณีแรกต้องจำลองโดยชี้ไคลเอนต์ไปยังพอร์ตที่ดึงแพ็กเก็ตตกหล่น เพื่อให้มั่นใจว่าข้อผิดพลาดถูกแสดงผลเป็นความล้มเหลวในการเชื่อมต่อ ไม่ใช่ข้อผิดพลาดจากการหมดเวลาอ่านข้อมูล
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น