इनबॉक्स कोलिजनशिवाय React इन्व्हाईट ईमेल्स टेस्ट करा
जेव्हा इन्व्हाईट फ्लोमुळे (invite flows) शेअर केलेला QA इनबॉक्स भरतो, तेव्हा प्रिव्ह्यू एन्व्हायरनमेंट्स (preview environments) निकामी होतात.
एक टेस्टर चुकीची लिंक उघडतो. दुसरा एखादा जुना मेसेज घेतो. React कोडमध्ये बिघाड आहे की बॅकएंडने जुना डेटा पाठवला आहे, यावरून टीममध्ये वाद होतात.
तुम्ही मेलबॉक्सला तुमच्या उत्पादनाचा (product) एक भाग मानले पाहिजे. जर तुमचे ऑनबोर्डिंग (onboarding) ईमेलवर अवलंबून असेल, तर तुमच्या प्रिव्ह्यू एन्व्हायरनमेंट्सना आयसोलेशन स्ट्रॅटेजीची (isolation strategy) गरज आहे. त्याशिवाय, तुमचा फीडबॅक लूप (feedback loop) मंदावतो.
प्रिव्ह्यू ब्रँचेस मधील सामान्य त्रुटी (failure modes):
- ईमेल लिंक जुन्या डिप्लॉयमेंटकडे (deployment) निर्देश करते.
- पुन्हा केलेले API कॉल्स एकाच युजरसाठी दोन इन्व्हाईट्स तयार करतात.
- UI इन्व्हाईट स्वीकारते पण जुना मेंबरशिप डेटा दाखवते.
- दुसऱ्या व्यक्तीने ब्रँच व्हॅलिडेट करण्यापूर्वीच एक टेस्टर टोकन वापरतो.
शेअर केलेले इनबॉक्सेस फ्लॅकी टेस्ट्स (flaky tests) आणि कमी विश्वासार्हता निर्माण करतात.
हे सुधारण्यासाठी ही सोपी प्रक्रिया वापरा:
- प्रिव्ह्यू एन्व्हायरनमेंटमधील रिअल React ॲडमिन स्क्रीनवरून इन्व्हाईट तयार करा.
- प्रोडक्शनप्रमाणेच (production) तेच बॅकएंड पाथ, टेम्पलेट्स आणि टोकन लॉजिक वापरा.
- मेसेज केवळ त्या रनसाठी तयार केलेल्या अल्पायुषी (short-lived) इनबॉक्सकडे वळवा.
- ब्राउझरमध्ये लिंक उघडा आणि ॲपची स्थिती (app state) तपासा.
क्विक ब्रँच व्हॅलिडेशनसाठी डिस्पोजेबल ईमेल जनरेटर्स (disposable email generators) चांगले काम करतात. ते तुमचा फ्लो सोपा ठेवतात.
एका चांगल्या प्रिव्ह्यू टेस्टमध्ये या गोष्टी तपासल्या पाहिजेत:
- ईमेलमध्ये त्या ब्रँचसाठी योग्य प्रिव्ह्यू होस्ट (preview host) आहे का.
- प्राप्तकर्त्यासाठी फक्त एकच सक्रिय इन्व्हाईट लिंक उपलब्ध आहे का.
- टोकन योग्य वर्कस्पेस (workspace) आणि रोलवर (role) पोहोचते का.
- React ॲप मॅन्युअल रीलोडशिवाय ॲक्सेस स्टेट अपडेट करते का.
- स्वीकारल्यानंतर लिंकवर दुसऱ्यांदा क्लिक केल्यास ती अयशस्वी होते का.
फ्रंटएंड असर्शन (frontend assertion) विसरू नका. बॅकएंड लॉग्समध्ये यश (success) दिसत असताना क्लायंटमध्ये अजूनही 'पेंडिंग' (pending) स्थिती असू शकते. युजर्सना हे लगेच लक्षात येते.
इन्व्हाईट निर्मितीपासून अंतिम ॲक्टिव्हेशनपर्यंत कोरिलेशन आयडी (correlation ID) जोडल्याने वेळ वाचतो. एन्व्हायरनमेंट व्हेरिएबल्समुळे (environment variables) टेम्पलेटमध्ये चुकीचा होस्ट शिरला आहे का, हे शोधण्यास यामुळे मदत होते.
उद्देश सर्वत्र डिस्पोजेबल इनबॉक्सेस वापरणे हा नाही. उद्देश वास्तववादी इन्व्हाईट पाथ (realistic invite path) वेगळा करणे हा आहे. यामुळे प्रोडक्शनमध्ये जाण्यापूर्वीच रिग्रेशन्स (regressions) पकडले जातात.
इन्व्हाईट फ्लो बदलावर विश्वास ठेवण्यापूर्वी ही चेकलिस्ट वापरा:
- ईमेल योग्य प्रिव्ह्यू डिप्लॉयमेंटला लिंक करतो.
- टोकन योग्य वर्कस्पेस आणि रोलला मॅप करते.
- दुसऱ्या क्लिकमध्ये तोच टोकन पुन्हा वापरला जात नाही.
- अतिरिक्त नेव्हिगेशनशिवाय स्वीकारलेली स्थिती (accepted state) UI मध्ये दिसते.
- मेलबॉक्स ओळखणे आणि काढून टाकणे सोपे आहे.