React میں لنکس کو مکس کیے بغیر ای میل تبدیلی کے بہاؤ (flows) کا ٹیسٹ کریں
اکاؤنٹ کی ای میل تبدیل کرنا ایک معمولی کام لگتا ہے۔ لیکن حقیقت میں یہ ٹیسٹنگ کی غلطیوں کا ایک بڑا ذریعہ ہے۔
ٹیسٹرز اکثر کنفرمیشن لنکس کو مکس کر دیتے ہیں۔ ایک شخص ایڈریس اپ ڈیٹ کرتا ہے جبکہ دوسرا شخص پہلے پیغام کھول لیتا ہے۔ اس سے الجھن پیدا ہوتی ہے۔ ٹیم اس بات پر بحث کرنے لگتی ہے کہ آیا React پیج خراب ہے یا لنک غلط صارف کا ہے۔
یہ مسئلہ اس لیے ہوتا ہے کیونکہ ٹیمیں ان باکس کو ایک مشترکہ ٹول کے طور پر استعمال کرتی ہیں۔ آپ کو ان باکس کو فیچر کنٹریکٹ (feature contract) کے ایک حصے کے طور پر دیکھنا چاہیے۔
ای میل تبدیلی کا عمل (journey) نازک ہوتا ہے۔ یہ ایک فعال اکاؤنٹ کو تبدیل کرتا ہے۔ صارف پہلے سے ہی لاگ ان ہوتا ہے۔ اکثر پینڈنگ (pending) ای میل اور کنفرم شدہ ای میل کی حالتوں کے درمیان ایک مقابلہ (race) ہوتا ہے۔
عام مسائل میں شامل ہیں:
- کنفرمیشن پیغامات ایک مشترکہ ان باکس میں آتے ہیں جنہیں ٹریک کرنے کا کوئی طریقہ نہیں ہوتا۔
- لنک کے ذریعے نئی درخواست کی تصدیق کے بعد بھی UI پر پرانا ڈیٹا نظر آتا ہے۔
- بیک اینڈ اپ ڈیٹ ہو جاتا ہے، لیکن فرنٹ اینڈ کیش (cache) پر پرانا ایڈریس نظر آتا ہے۔
- ایک ٹیسٹر کسی دوسرے شخص کے لیے مخصوص لنک پر کلک کر دیتا ہے۔
ایک مشترکہ میل باکس بگ (bug) کی وجہ تلاش کرنا مشکل بنا دیتا ہے۔ ایک ہی اسٹیجنگ ایلیئس (staging alias) کے بجائے ہر ٹیسٹ رن کے لیے ایک منفرد برنر (burner) ای میل ایڈریس استعمال کریں۔
اس صاف ستھرے تسلسل پر عمل کریں:
- ایک ٹیسٹ صارف بنائیں۔
- React سیٹنگز اسکرین میں ای میل تبدیلی کی درخواست کریں۔
- اصل بیک اینڈ پاتھ کے ذریعے میل بھیجیں۔
- پیغام کو ایسے ان باکس میں بھیجیں جو صرف اسی ٹیسٹ کا ہو۔
- لنک کھولیں اور تصدیق کریں کہ سیٹنگز اسکرین نئے ایڈریس کے ساتھ ریفریش ہو رہی ہے۔
اس سے ملکیت (ownership) واضح رہتی ہے۔ آپ کو معلوم ہوگا کہ کون سا لنک کس صارف کا تھا۔
React ایپس کے لیے، ایک اضافی اصول پر عمل کریں۔ اسکرین کی تصدیق (assert) صرف تازہ ڈیٹا پڑھنے کے بعد کریں۔ آپٹیمسٹک کلائنٹ اسٹیٹ (optimistic client state) پر بھروسہ نہ کریں۔ ایک میوٹیشن (mutation) کامیابی کا نتیجہ دے سکتی ہے، لیکن اگر بیک اینڈ نے تبدیلی کو حتمی شکل نہیں دی تو پیج ری لوڈ کرنے سے پرانی ویلیو واپس آ سکتی ہے۔
ایک اچھے اینڈ ٹو اینڈ (end-to-end) ٹیسٹ کو ان نکات کی تصدیق کرنی چاہیے:
- ای میل پینڈنگ ایڈریس پر گئی، پرانے ایڈریس پر نہیں۔
- لنک درست انوائرمنٹ ہوسٹ (environment host) کی طرف اشارہ کرتا ہے۔
- لنک اکاؤنٹ ریکارڈ کو اپ ڈیٹ کرتا ہے۔
- ری فیش (refetch) کے بعد پرانا ایڈریس غائب ہو جاتا ہے۔
- ایک ہی لنک کو دوبارہ استعمال کرنے سے محفوظ طریقے سے ناکامی (fail) ہوتی ہے۔
اگر آپ کا React کوئری کیش (query cache) یا کلائنٹ اسٹور پرانا (stale) ہے، تو فیچر خراب محسوس ہوتا ہے۔ صارف کو صرف اس سے مطلب ہے کہ آیا سیٹنگز اسکرین حقیقت دکھاتی ہے۔
آپ کو ہر درخواست کے ساتھ ایک کورلیشن آئی ڈی (correlation ID) بھی شامل کرنی چاہیے۔ یہ آپ کو صارف سے لے کر پیغام کی ڈیلیوری اور حتمی تصدیق تک درخواست کو ٹریس کرنے میں مدد دیتا ہے۔
الگ تھلگ ان باکسز یونٹ ٹیسٹ (unit tests) کا متبادل نہیں ہیں۔ فارم ویلیڈیشن اور API کی غلطیوں کے لیے یونٹ ٹیسٹ استعمال کریں۔ ان باکس فلو کا استعمال یہ ثابت کرنے کے لیے کریں کہ اصل کسٹمر پاتھ تمام سسٹمز پر کام کر رہا ہے۔
اکاؤنٹ سیٹنگز میں تبدیلیاں بھیجنے (ship) سے پہلے، ان چیزوں کو چیک کریں:
- اصل React UI سے تبدیلی کی درخواست کریں۔
- تصدیق کریں کہ پیغام مخصوص رن (run-specific) کے ان باکس میں پہنچتا ہے۔
- تصدیق کریں کہ ری فیش (refetch) کے بعد نیا ایڈریس نظر آتا ہے۔
- یقینی بنائیں کہ پرانے لنک کو دوبارہ استعمال نہیں کیا جا سکتا۔
- تصدیق کریں کہ آڈٹ لاگز (audit logs) دکھاتے ہیں کہ تبدیلی کس نے شروع کی۔
یہ ان بگ (bugs) کو روکتا ہے جہاں علیحدگی میں سب کچھ ٹھیک لگتا ہے لیکن حقیقی دنیا میں ناکام ہو جاتا ہے۔