ทดสอบขั้นตอนการเปลี่ยนอีเมลใน React โดยไม่สับสนเรื่องลิงก์
การเปลี่ยนอีเมลบัญชีดูเหมือนจะเป็นเรื่องเล็กน้อย แต่จริงๆ แล้วมันเป็นสาเหตุหลักของข้อผิดพลาดในการทดสอบ
ผู้ทดสอบมักจะสับสนลิงก์ยืนยัน คนหนึ่งกำลังอัปเดตที่อยู่ ในขณะที่อีกคนเปิดข้อความก่อน สิ่งนี้ทำให้เกิดความสับสน ทีมงานจะเริ่มถกเถียงกันว่าหน้า React เสีย หรือลิงก์นั้นเป็นของยูสเซอร์ผิดคนกันแน่
ปัญหานี้เกิดขึ้นเพราะทีมมองว่ากล่องจดหมาย (inbox) เป็นเครื่องมือที่ใช้ร่วมกัน คุณต้องมองว่ากล่องจดหมายเป็นส่วนหนึ่งของข้อตกลงของฟีเจอร์ (feature contract)
ขั้นตอนการเปลี่ยนอีเมลนั้นเปราะบาง เพราะมันเป็นการเปลี่ยนข้อมูลในบัญชีที่กำลังใช้งานอยู่ ผู้ใช้ล็อกอินค้างไว้แล้ว และมักจะเกิดการแย่งชิงกัน (race condition) ระหว่างสถานะอีเมลที่รอดำเนินการ (pending) และอีเมลที่ยืนยันแล้ว (confirmed)
ปัญหาที่พบบ่อย ได้แก่:
- ข้อความยืนยันส่งมาที่กล่องจดหมายที่ใช้ร่วมกัน ทำให้ไม่มีวิธีติดตาม
- UI แสดงข้อมูลเก่า แม้ว่าลิงก์จะยืนยันคำขอใหม่แล้วก็ตาม
- Backend อัปเดตแล้ว แต่ frontend cache ยังแสดงที่อยู่เดิม
- ผู้ทดสอบคนหนึ่งคลิกลิงก์ที่ตั้งใจไว้สำหรับอีกคนหนึ่ง
การใช้กล่องจดหมายร่วมกันทำให้หาต้นตอของบั๊กได้ยาก ควรใช้ที่อยู่อีเมลชั่วคราว (burner email) ที่ไม่ซ้ำกันสำหรับการทดสอบแต่ละครั้ง แทนที่จะใช้ staging alias เพียงอันเดียว
ทำตามลำดับขั้นตอนที่ชัดเจนดังนี้:
- สร้างผู้ใช้สำหรับทดสอบ
- ส่งคำขอเปลี่ยนอีเมลในหน้าการตั้งค่าของ React
- ส่งอีเมลผ่านเส้นทาง backend จริง
- ส่งข้อความไปยังกล่องจดหมายที่เป็นของชุดการทดสอบนี้เท่านั้น
- เปิดลิงก์และตรวจสอบว่าหน้าการตั้งค่ารีเฟรชด้วยที่อยู่ใหม่แล้ว
วิธีนี้จะทำให้การเป็นเจ้าของข้อมูลชัดเจน คุณจะรู้ว่าลิงก์ไหนมาจากผู้ใช้คนไหน
สำหรับแอป React ให้ทำตามกฎเพิ่มเติมหนึ่งข้อ คือ ให้ตรวจสอบหน้าจอ (assert) หลังจากที่มีการอ่านข้อมูลใหม่ (fresh data read) เท่านั้น อย่าเชื่อถือ optimistic client state เพราะการทำ mutation อาจส่งผลลัพธ์ว่าสำเร็จ แต่การรีโหลดหน้าเว็บอาจดึงค่าเก่ากลับมาหาก backend ยังไม่ได้สรุปการเปลี่ยนแปลงให้เสร็จสิ้น
การทดสอบแบบ end-to-end ที่ดีต้องตรวจสอบประเด็นเหล่านี้:
- อีเมลถูกส่งไปยังที่อยู่ที่รอดำเนินการ ไม่ใช่ที่อยู่เดิม
- ลิงก์ชี้ไปยัง host ของสภาพแวดล้อม (environment) ที่ถูกต้อง
- ลิงก์ทำการอัปเดตข้อมูลบัญชี
- ที่อยู่เดิมหายไปหลังจากมีการ refetch
- การใช้ลิงก์เดิมซ้ำต้องล้มเหลวอย่างปลอดภัย (fails safely)
หาก React query cache หรือ client store ของคุณไม่อัปเดต (stale) ฟีเจอร์จะดูเหมือนเสีย ลูกค้าสนใจเพียงแค่ว่าหน้าการตั้งค่าแสดงข้อมูลที่เป็นความจริงหรือไม่
คุณควรเพิ่ม correlation ID ในแต่ละคำขอด้วย สิ่งนี้จะช่วยให้คุณติดตามคำขอตั้งแต่ผู้ใช้ ไปจนถึงการส่งข้อความ และการยืนยันขั้นสุดท้าย
การแยกกล่องจดหมายไม่ได้มาแทนที่ unit tests ให้ใช้ unit tests สำหรับการตรวจสอบความถูกต้องของฟอร์ม (form validation) และข้อผิดพลาดของ API ส่วนการทดสอบผ่านกล่องจดหมาย (inbox flow) ให้ใช้เพื่อพิสูจน์ว่าเส้นทางจริงของลูกค้าทำงานได้ถูกต้องในทุกระบบ
ก่อนที่คุณจะส่งการเปลี่ยนแปลงไปยังการตั้งค่าบัญชี ให้ตรวจสอบรายการเหล่านี้:
- ส่งคำขอเปลี่ยนจาก React UI จริง
- ยืนยันว่าข้อความไปถึงกล่องจดหมายที่ระบุไว้สำหรับการทดสอบนั้นๆ
- ตรวจสอบว่าที่อยู่ใหม่แสดงขึ้นมาหลังจากมีการ refetch
- ตรวจสอบให้แน่ใจว่าลิงก์เก่าไม่สามารถนำกลับมาใช้ใหม่ได้
- ยืนยันว่า audit logs แสดงว่าใครเป็นคนเริ่มการเปลี่ยนแปลง
วิธีนี้จะช่วยป้องกันบั๊กที่ทุกอย่างดูเหมือนจะปกติเมื่อทดสอบแยกกัน แต่กลับล้มเหลวในโลกความเป็นจริง