اختبار تدفقات تغيير البريد الإلكتروني في React دون خلط الروابط
يبدو تغيير البريد الإلكتروني للحساب أمراً بسيطاً، لكنه في الواقع مصدر رئيسي لأخطاء الاختبار.
غالباً ما يخلط المختبرون بين روابط التأكيد. يقوم شخص بتحديث عنوان ما بينما يفتح شخص آخر الرسالة أولاً. هذا يسبب ارتباكاً؛ حيث يبدأ الفريق في التساؤل عما إذا كانت صفحة React معطلة أم أن الرابط يخص مستخدماً خاطئاً.
تحدث هذه المشكلة لأن الفرق تتعامل مع صندوق الوارد كأداة مشتركة. يجب عليك التعامل مع صندوق الوارد كجزء من عقد الميزة (feature contract).
رحلات تغيير البريد الإلكتروني هشة؛ فهي تغير حساباً نشطاً، حيث يكون المستخدم مسجلاً للدخول بالفعل. وغالباً ما يكون هناك سباق بين حالة البريد الإلكتروني المعلق وحالة البريد الإلكتروني المؤكد.
تشمل المشكلات الشائعة ما يلي:
- تصل رسائل التأكيد إلى صندوق وارد مشترك دون وسيلة لتتبعها.
- تعرض واجهة المستخدم (UI) بيانات قديمة حتى بعد تأكيد الرابط للطلب الجديد.
- يتم تحديث الخلفية (backend)، ولكن ذاكرة التخزين المؤقت للواجهة الأمامية (frontend cache) تعرض العنوان القديم.
- ينقر أحد المختبرين على رابط مخصص لشخص آخر.
تجعل البريد المشترك من الصعب العثور على سبب الخطأ. استخدم عنوان بريد إلكتروني مؤقت (burner email) فريد لكل عملية اختبار بدلاً من اسم مستعار واحد لبيئة الاختبار (staging alias).
اتبع هذا التسلسل المنظم:
- إنشاء مستخدم اختبار.
- طلب تغيير البريد الإلكتروني في شاشة إعدادات React.
- إرسال البريد عبر مسار الخلفية (backend) الحقيقي.
- توجيه الرسالة إلى صندوق وارد يخص هذا الاختبار فقط.
- فتح الرابط والتحقق من تحديث شاشة الإعدادات بالعنوان الجديد.
هذا يحافظ على وضوح الملكية، حيث ستعرف أي رابط جاء من أي مستخدم.
بالنسبة لتطبيقات React، اتبع قاعدة إضافية واحدة: تحقق من الشاشة فقط بعد قراءة البيانات الجديدة. لا تثق في حالة العميل المتفائلة (optimistic client state). قد تعيد عملية التعديل (mutation) نتيجة نجاح، ولكن إعادة تحميل الصفحة قد تعيد القيمة القديمة إذا لم يقم الـ backend بإنهاء التغيير.
يجب أن يتحقق اختبار الطرف إلى الطرف (end-to-end test) الجيد من هذه النقاط:
- تم إرسال البريد إلى العنوان المعلق وليس العنوان القديم.
- يشير الرابط إلى المضيف (host) الصحيح للبيئة.
- يقوم الرابط بتحديث سجل الحساب.
- يختفي العنوان القديم بعد إعادة جلب البيانات (refetch).
- فشل إعادة استخدام نفس الرابط بشكل آمن.
إذا كانت ذاكرة التخزين المؤقت لـ React query أو مخزن العميل (client store) قديمة، فستبدو الميزة معطلة. لا يهتم العميل إلا بما إذا كانت شاشة الإعدادات تعرض الواقع.
يجب عليك أيضاً إضافة معرف ارتباط (correlation ID) لكل طلب. يساعدك هذا في تتبع الطلب من المستخدم إلى تسليم الرسالة والتأكيد النهائي.
صناديق الوارد المعزولة لا تحل محل اختبارات الوحدة (unit tests). استخدم اختبارات الوحدة للتحقق من صحة النماذج وأخطاء الـ API. استخدم تدفق صندوق الوارد لإثبات أن مسار العميل الحقيقي يعمل عبر جميع الأنظمة.
قبل إرسال التغييرات إلى إعدادات الحساب، تحقق من هذه العناصر:
- اطلب التغيير من واجهة مستخدم React الحقيقية.
- تأكد من وصول الرسالة إلى صندوق وارد خاص بتلك العملية.
- تحقق من ظهور العنوان الجديد بعد إعادة جلب البيانات (refetch).
- تأكد من عدم إمكانية إعادة استخدام الرابط القديم.
- تأكد من أن سجلات التدقيق (audit logs) تظهر من بدأ التغيير.
هذا يمنع حدوث أخطاء حيث يبدو كل شيء جيداً في العزل ولكنه يفشل في العالم الحقيقي.