ทำ contract test จากกรณีสำเร็จและผิดพลาด

1. ระบุปัญหาของสัญญาข้อมูล

test ที่มีแต่ response สำเร็จพิสูจน์ได้แค่เส้นทางที่ง่าย ต้องตรวจว่า client ไม่สร้างเงินหรือเครดิตจาก body ที่ไม่ครบด้วย

OpenAPI แยกคำอธิบาย operation, schema และตัวอย่างออกจากกัน จึงต้องอ่านข้อกำหนดของ field ไม่อนุมานจากตัวอย่างเดียว

2. ขั้นตอนตรวจฝั่ง integration

ทำงานนี้ใน backend หรือชุดทดสอบของร้าน แยกข้อมูลจำลองจากระบบจริง และไม่เพิ่มสิทธิ์เกินงานเพื่อให้ test ผ่าน

• ทำ fixture จำลองสำหรับ success validation unauthorized และผลไม่แน่ชัด
• ทดสอบทั้ง HTTP และ body โดยคง field จำเป็นของแต่ละผลิตภัณฑ์
• แยก test serializer/parser ออกจาก integration test ที่ต้องได้รับอนุญาต

3. ตัวอย่างจำลองและผลที่ควรตรวจ

ตัวระบุ ยอด และเหตุการณ์ต่อไปเป็นตัวอย่าง ไม่ใช่ credentials หรือข้อมูลบัญชีที่นำไปใช้จริงได้

4. สิ่งที่ห้ามอนุมานเพิ่ม

อย่าใช้ success predicate เดียวกับ gift-envelope เพราะโครงสร้างสำเร็จต่างกันตาม payment.md และ mock ผ่านไม่ยืนยันว่า production ตั้งค่าถูก

5. จุดตรวจใน MeeTang

อ่าน Payment Docs กับ API Docs แล้วบันทึก test cases โดยไม่ใช้ key หรือหลักฐานเงินจริง

พฤติกรรมผลิตภัณฑ์ในบทความตรวจจากสัญญาและ source ของ repository วันที่ 27 กันยายน 2026 ไม่ใช่ผลทดสอบ deployment จริง จึงต้องตรวจสัญญาที่ใช้งานก่อนเปิดส่งข้อมูล

แหล่งอ้างอิงและขอบเขตเนื้อหา

แหล่งต่อไปนี้อธิบายหลักการทั่วไป ส่วนขั้นตอนของ MeeTang ตรวจจากฟีเจอร์ในระบบ ณ วันที่อัปเดต ตัวเลขในตัวอย่างไม่ใช่ข้อมูลผู้ใช้งานจริง

• OpenAPI Specification 3.1.1 — โครงสร้าง operation, schema, required และตัวอย่าง

จัดทำด้วย AI ช่วยเรียบเรียงและตรวจเทียบกับโค้ด ไม่ใช่คำแนะนำภาษีหรือการรับรองผลทางบัญชี เงื่อนไขฟีเจอร์และโควตาขึ้นกับแพ็กเกจและสิทธิ์ที่ได้รับ