ทดสอบขั้นตอนการเปลี่ยนอีเมลโดยไม่พลาดลิงก์สำคัญ
การเปลี่ยนอีเมลบัญชีดูเหมือนจะเป็นเรื่องเล็กน้อย แต่มันคือกับดักที่พบบ่อยสำหรับทีม QA เมื่อเทสเตอร์คนหนึ่งอัปเดตที่อยู่ใหม่ แต่อีกคนดันเปิดอีเมลนั้นก่อน ผลที่ตามมาคือทีมต้องมาถกเถียงกันว่าหน้า React เสีย หรือว่าลิงก์นั้นเป็นของยูสเซอร์ผิดคนกันแน่
ความสับสนนี้เกิดขึ้นเมื่อคุณมองว่ากล่องจดหมาย (inbox) เป็นเพียงเครื่องมือที่ใช้ร่วมกัน แทนที่จะมองว่าเป็นส่วนหนึ่งของฟีเจอร์
ขั้นตอนการเปลี่ยนอีเมลนั้นมีความเปราะบาง เพราะมันเป็นการแก้ไขบัญชีที่กำลังใช้งานอยู่ คุณต้องจัดการกับผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว (authenticated users) และสถานะที่ยังค้างอยู่ (pending states)
ปัญหาที่พบบ่อย ได้แก่:
- ข้อความถูกส่งไปยังกล่องจดหมายที่ใช้ร่วมกันโดยไม่มีเจ้าของที่ชัดเจน
- ลิงก์ใช้งานได้ แต่ UI แสดงข้อมูลเก่า
- Backend อัปเดตแล้ว แต่แคชของ Frontend ยังเป็นข้อมูลเก่า (stale)
- เทสเตอร์เผลอคลิกลิงก์ที่ตั้งใจไว้ให้เทสเตอร์คนอื่น
เพื่อแก้ไขปัญหานี้ ให้ใช้ burner email สำหรับการทดสอบแต่ละรอบ ห้ามใช้ staging alias เพียงอันเดียวซ้ำๆ
ทำตามลำดับขั้นตอนดังนี้:
- สร้างผู้ใช้สำหรับทดสอบผ่านแอป
- ส่งคำขอเปลี่ยนอีเมลในส่วนการตั้งค่าของ React
- ส่งอีเมลผ่าน backend จริง
- ส่งข้อความไปยังกล่องจดหมายที่ใช้สำหรับการทดสอบรอบเดียว (one-run inbox)
- เปิดลิงก์และตรวจสอบว่าหน้าจอการตั้งค่าแสดงที่อยู่ใหม่แล้ว
การแยกส่วน (Isolation) ช่วยให้ระบุเจ้าของได้ชัดเจน คุณไม่จำเป็นต้องจดโน้ตยุ่งเหยิงใน Slack เพื่อจำว่าใช้กล่องจดหมายไหนไป
กฎสำหรับแอป React: ให้ตรวจสอบหน้าจอตลอดเวลาหลังจากที่มีการอ่านข้อมูลใหม่ (fresh data read) อย่าเชื่อใจ optimistic client state เพราะแม้ว่า mutation จะส่งผลลัพธ์กลับมาว่าสำเร็จ แต่การรีโหลดหน้าเว็บอาจดึงค่าเก่ากลับมาได้ ซึ่งเรื่องนี้เกิดขึ้นบ่อยกว่าที่คนส่วนใหญ่ยอมรับเสียอีก
การทดสอบแบบ end-to-end ของคุณต้องตรวจสอบว่า:
- อีเมลถูกส่งไปยังที่อยู่ใหม่ที่อยู่ในสถานะรอการยืนยัน (pending address)
- ลิงก์ชี้ไปยัง host ที่ถูกต้อง
- ลิงก์ทำการอัปเดตข้อมูลบัญชี
- ที่อยู่เก่าหายไปหลังจากมีการ refetch ข้อมูล
- การใช้ลิงก์ซ้ำต้องล้มเหลวอย่างปลอดภัย (fails safely)
การทำ Frontend assertions คือส่วนที่สำคัญที่สุด Log ของ backend ที่บอกว่าสำเร็จจะไม่มีประโยชน์เลยหากผู้ใช้ยังเห็นที่อยู่ผิด หากแคชหรือ store ของคุณยังเป็นข้อมูลเก่า (stale) แสดงว่าฟีเจอร์นั้นพังแล้ว
การตรวจสอบย้อนกลับ (Traceability) ก็ช่วยได้เช่นกัน ให้ใช้ correlation ID ใน log และ email metadata เพื่อเชื่อมโยงคำขอ (request) เข้ากับการส่งอีเมลและการยืนยัน
ข้อควรพิจารณา (Tradeoffs):
- การทำ inbox polling ช้ากว่าการใช้ mocks
- ที่อยู่แบบใช้แล้วทิ้ง (disposable addresses) ต้องใช้เก็บเฉพาะข้อมูลที่ไม่ใช่ข้อมูลจริง (non-production data) เท่านั้น
- สภาพแวดล้อมสำหรับพรีวิว (Preview environments) จำเป็นต้องมีกฎในการล้างข้อมูล (cleanup rules)
อย่าข้ามขั้นตอนนี้ เพราะขั้นตอนการทำงานของอีเมลมักจะพังในช่วงรอยต่อระหว่างระบบ และนั่นคือจุดที่ mocks ทำงานได้ไม่ครอบคลุมที่สุด