इनबॉक्स टकराव (collisions) के बिना React इनवाइट ईमेल का परीक्षण करें
जब इनवाइट फ्लो (invite flows) एक साझा QA इनबॉक्स को भर देते हैं, तो प्रिव्यू एनवायरनमेंट (preview environments) विफल हो जाते हैं।
एक टेस्टर गलत लिंक खोल लेता है। दूसरा कोई पुराना मैसेज उठा लेता है। टीम इस बात पर बहस करने लगती है कि क्या React कोड खराब है या बैकएंड ने पुराना डेटा भेजा है।
आपको मेलबॉक्स को अपने प्रोडक्ट के एक हिस्से के रूप में मानना चाहिए। यदि आपका ऑनबोर्डिंग (onboarding) ईमेल पर निर्भर है, तो आपके प्रिव्यू एनवायरनमेंट को एक आइसोलेशन स्ट्रैटेजी (isolation strategy) की आवश्यकता है। इसके बिना, आपका फीडबैक लूप धीमा हो जाता है।
प्रिव्यू ब्रांचेस (preview branches) में सामान्य विफलता के तरीके:
- ईमेल लिंक किसी पुराने डिप्लॉयमेंट (deployment) की ओर इशारा करता है।
- दोबारा किए गए API कॉल्स एक ही यूजर के लिए दो इनवाइट बना देते हैं।
- UI इनवाइट को स्वीकार कर लेता है लेकिन पुराना मेंबरशिप डेटा दिखाता है।
- एक टेस्टर दूसरे व्यक्ति द्वारा ब्रांच को वैलिडेट करने से पहले ही टोकन का उपयोग कर लेता है।
साझा इनबॉक्स अस्थिर (flaky) टेस्ट और कम भरोसे का कारण बनते हैं।
इसे ठीक करने के लिए इस सरल प्रक्रिया का उपयोग करें:
- प्रिव्यू एनवायरनमेंट में असली React एडमिन स्क्रीन से इनवाइट बनाएं।
- प्रोडक्शन की तरह ही समान बैकएंड पाथ, टेम्पलेट्स और टोकन लॉजिक का उपयोग करें।
- मैसेज को केवल उस रन के लिए बनाए गए अल्पकालिक (short-lived) इनबॉक्स में भेजें।
- ब्राउज़र में लिंक खोलें और ऐप की स्थिति (state) की जांच करें।
क्विक ब्रांच वैलिडेशन (quick branch validation) के लिए डिस्पोजेबल ईमेल जनरेटर अच्छे से काम करते हैं। वे आपके फ्लो को सरल रखते हैं।
एक अच्छे प्रिव्यू टेस्ट में इन चीजों की जांच होनी चाहिए:
- ईमेल में उस ब्रांच के लिए सही प्रिव्यू होस्ट (preview host) होना चाहिए।
- प्राप्तकर्ता के लिए केवल एक ही सक्रिय इनवाइट लिंक मौजूद हो।
- टोकन सही वर्कस्पेस और रोल पर पहुंचता है।
- React ऐप बिना मैनुअल रीलोड के एक्सेस स्टेट को अपडेट कर देता है।
- स्वीकार करने के बाद लिंक पर दूसरी बार क्लिक करने पर वह विफल हो जाता है।
फ्रंटएंड एसर्शन (frontend assertion) को न भूलें। बैकएंड लॉग्स सफलता दिखा सकते हैं जबकि क्लाइंट अभी भी पेंडिंग स्टेट दिखा सकता है। यूजर्स इसे तुरंत नोटिस कर लेते हैं।
इनवाइट क्रिएशन से लेकर फाइनल एक्टिवेशन तक एक कोरिलेशन आईडी (correlation ID) जोड़ने से समय बचता है। यह आपको यह पता लगाने में मदद करता है कि क्या एनवायरनमेंट वेरिएबल्स के कारण टेम्पलेट में गलत होस्ट आ गया है।
लक्ष्य हर जगह डिस्पोजेबल इनबॉक्स का उपयोग करना नहीं है। लक्ष्य वास्तविक इनवाइट पाथ को आइसोलेट करना है। यह प्रोडक्शन तक पहुँचने से पहले ही रिग्रेशन (regressions) को पकड़ लेता है।
इनवाइट फ्लो में बदलाव पर भरोसा करने से पहले इस चेकलिस्ट का उपयोग करें:
- ईमेल सही प्रिव्यू डिप्लॉयमेंट से लिंक है।
- टोकन सही वर्कस्पेस और रोल से मैप होता है।
- दूसरी बार क्लिक करने पर वही टोकन दोबारा इस्तेमाल नहीं होता है।
- बिना किसी अतिरिक्त नेविगेशन के UI में एक्सेप्टेड स्टेट दिखाई देती है।
- मेलबॉक्स को पहचानना और हटाना आसान है।
