ای میل تبدیلی کے بہاؤ (flows) کی جانچ کریں تاکہ کوئی لنک چھوٹ نہ جائے
اکاؤنٹ کی ای میل تبدیل کرنا ایک معمولی کام لگتا ہے۔ یہ QA ٹیموں کے لیے ایک عام جال ہے۔ ایک ٹیسٹر ایڈریس اپ ڈیٹ کرتا ہے۔ دوسرا شخص پہلے ای میل کھول لیتا ہے۔ اب ٹیم اس بات پر بحث کرتی ہے کہ آیا React پیج خراب ہے یا لنک غلط صارف کا تھا۔
یہ الجھن اس وقت ہوتی ہے جب آپ ان باکس کو فیچر کے حصے کے بجائے ایک مشترکہ ٹول کے طور پر استعمال کرتے ہیں۔
ای میل تبدیلی کے مراحل (journeys) نازک ہوتے ہیں۔ یہ فعال اکاؤنٹس میں تبدیلی لاتے ہیں۔ آپ کو مستند صارفین (authenticated users) اور زیر التواء حالتوں (pending states) کے ساتھ نمٹنا پڑتا ہے۔
عام مسائل میں شامل ہیں:
- پیغامات کسی ایسے مشترکہ ان باکس میں آتے ہیں جس کا کوئی واضح مالک نہیں ہوتا۔
- لنک کام کرتا ہے، لیکن UI پر پرانا ڈیٹا نظر آتا ہے۔
- بیک اینڈ اپ ڈیٹ ہو جاتا ہے، لیکن فرنٹ اینڈ کیش (cache) پرانا ہی رہتا ہے۔
- ٹیسٹرز دوسرے ٹیسٹرز کے لیے بنائے گئے لنکس پر کلک کر دیتے ہیں۔
اسے ٹھیک کرنے کے لیے، ہر ٹیسٹ رن کے لیے ایک برنر (burner) ای میل استعمال کریں۔ ایک ہی اسٹیجنگ ایلیئس (staging alias) استعمال نہ کریں۔
اس ترتیب پر عمل کریں:
- ایپ کے ذریعے ایک ٹیسٹ صارف بنائیں۔
- React سیٹنگز میں ای میل تبدیلی کی درخواست کریں۔
- اصل بیک اینڈ کے ذریعے میل بھیجیں۔
- پیغام کو ایک بار استعمال ہونے والے (one-run) ان باکس کی طرف بھیجیں۔
- لنک کھولیں اور تصدیق کریں کہ سیٹنگز اسکرین پر نیا ایڈریس نظر آ رہا ہے۔
علیحدگی (Isolation) ملکیت کو واضح رکھتی ہے۔ آپ کو یہ یاد رکھنے کے لیے Slack پر الجھے ہوئے نوٹس لکھنے کی ضرورت نہیں پڑے گی کہ آپ نے کون سا ان باکس استعمال کیا تھا۔
React ایپس کے لیے ایک اصول: تازہ ڈیٹا پڑھنے کے بعد ہمیشہ اسکرین چیک کریں۔ optimistic client state پر بھروسہ نہ کریں۔ میوٹیشن (mutation) کامیابی کا نتیجہ دے سکتی ہے، لیکن پیج ری لوڈ کرنے سے پرانی ویلیو واپس آ سکتی ہے۔ یہ اس سے کہیں زیادہ ہوتا ہے جتنا لوگ تسلیم کرتے ہیں۔
آپ کے اینڈ ٹو اینڈ (end-to-end) ٹیسٹ کو ان چیزوں کی تصدیق کرنی چاہیے:
- ای میل نئے زیر التواء (pending) ایڈریس پر جائے۔
- لنک درست ہوسٹ (host) کی طرف اشارہ کرے۔
- لنک اکاؤنٹ ریکارڈ کو اپ ڈیٹ کرے۔
- ری فیس (refetch) کے بعد پرانا ایڈریس غائب ہو جائے۔
- لنک کا دوبارہ استعمال کرنے پر سسٹم محفوظ طریقے سے ناکام ہو جائے۔
فرنٹ اینڈ اسپرشنز (assertions) سب سے اہم حصہ ہیں۔ اگر صارف غلط ایڈریس دیکھ رہا ہے تو بیک اینڈ لاگ کا 'success' کہنا بیکار ہے۔ اگر آپ کا کیش (cache) یا اسٹور پرانا ہے، تو فیچر خراب ہے۔
ٹریس ایبلٹی (Traceability) بھی مددگار ثابت ہوتی ہے۔ اپنے لاگز اور ای میل میٹا ڈیٹا میں ایک correlation ID استعمال کریں۔ یہ درخواست کو ڈیلیوری اور تصدیق سے جوڑتا ہے۔
غور کرنے کے لیے تجارتی نقصانات (Tradeoffs):
- ان باکس پولنگ (polling) مکس (mocks) سے زیادہ سست ہوتی ہے۔
- ڈسپوزایبل ایڈریسز میں صرف غیر پیداواری (non-production) ڈیٹا ہونا چاہیے۔
- پری ویو (preview) ماحول کے لیے صفائی کے اصولوں (cleanup rules) کی ضرورت ہوتی ہے۔
اسے نظر انداز نہ کریں۔ ای میل بہاؤ (flows) سسٹمز کے درمیان کے خلا میں ٹوٹ جاتے ہیں۔ یہ وہ جگہ ہے جہاں mocks سب سے کمزور ہوتے ہیں۔