लिंक्स गमावू नका: ईमेल बदलण्याच्या प्रक्रियेचे (flows) परीक्षण करा
खात्याचा ईमेल बदलणे ही गोष्ट छोटी वाटते. पण QA टीम्ससाठी हा एक सामान्य सापळा आहे. एक टेस्टर पत्ता अपडेट करतो. दुसरा व्यक्ती आधी ईमेल उघडतो. आता टीममध्ये वाद होतो की React पेज खराब झाले आहे की ती लिंक चुकीच्या वापरकर्त्याची होती.
जेव्हा तुम्ही इनबॉक्सला फीचरचा भाग मानण्याऐवजी एक सामायिक (shared) साधन म्हणून पाहता, तेव्हा अशी गोंधळाची स्थिती निर्माण होते.
ईमेल बदलण्याची प्रक्रिया नाजूक असते. त्या सक्रिय खात्यांमध्ये बदल करतात. तुम्हाला ऑथेंटिकेटेड (authenticated) वापरकर्ते आणि प्रलंबित (pending) स्थितींशी (states) व्यवहार करावा लागतो.
सामान्य समस्यांमध्ये खालील गोष्टींचा समावेश होतो:
- संदेश कोणत्याही स्पष्ट मालकाशिवाय एका सामायिक इनबॉक्समध्ये येतात.
- लिंक काम करते, पण UI जुना डेटा दाखवते.
- बॅकएंड अपडेट होते, पण फ्रंटएंड कॅशे (cache) जुनाच राहतो.
- टेस्टर्स इतर टेस्टर्ससाठी असलेल्या लिंक्सवर क्लिक करतात.
हे सुधारण्यासाठी, प्रत्येक टेस्ट रनसाठी एक 'बर्नर ईमेल' (burner email) वापरा. एकाच स्टेजिंग अलिआसचा (staging alias) वापर करू नका.
या क्रमाचे पालन करा:
- ॲपद्वारे एक टेस्ट युजर तयार करा.
- React सेटिंग्समध्ये ईमेल बदलण्याची विनंती करा.
- रिअल बॅकएंडद्वारे मेल पाठवा.
- संदेश एका 'वन-रन इनबॉक्स'कडे (one-run inbox) वळवा.
- लिंक उघडा आणि सेटिंग्स स्क्रीनवर नवीन पत्ता दिसत असल्याची खात्री करा.
आयसोलेशनमुळे (Isolation) मालकी हक्क स्पष्ट राहतो. तुम्ही कोणता इनबॉक्स वापरला होता हे लक्षात ठेवण्यासाठी तुम्हाला Slack मध्ये गोंधळात टाकणाऱ्या नोट्सची गरज पडणार नाही.
React ॲप्ससाठी एक नियम: डेटा नवीन वाचल्यानंतर (fresh data read) नेहमी स्क्रीन तपासा. 'ऑप्टिमिस्टिक क्लायंट स्टेट'वर (optimistic client state) विश्वास ठेवू नका. म्यूटेशन (mutation) यशस्वी झाल्याचे सूचित करू शकते, परंतु पेज रीलोड केल्यावर जुनी व्हॅल्यू पुन्हा येऊ शकते. हे लोक मान्य करण्यापेक्षा जास्त वेळा घडते.
तुमच्या एंड-टू-एंड (end-to-end) टेस्टमध्ये खालील गोष्टींची पडताळणी होणे आवश्यक आहे:
- ईमेल नवीन प्रलंबित (pending) पत्त्यावर जातो.
- लिंक योग्य होस्टला (host) निर्देशित करते.
- लिंक खाते रेकॉर्ड अपडेट करते.
- रिफॅच (refetch) नंतर जुना पत्ता निघून जातो.
- लिंकचा पुन्हा वापर केल्यास ती सुरक्षितपणे फेल होते.
फ्रंटएंड असर्शन्स (Frontend assertions) हा सर्वात महत्त्वाचा भाग आहे. जर वापरकर्त्याला चुकीचा पत्ता दिसत असेल, तर बॅकएंड लॉगमध्ये 'सक्सेस' (success) असे म्हणणे निरर्थक आहे. जर तुमचा कॅशे (cache) किंवा स्टोअर (store) जुना (stale) असेल, तर ते फीचर खराब झाले आहे असे समजावे.
ट्रेसॅबिलिटीमुळे (Traceability) देखील मदत होते. तुमच्या लॉग्स आणि ईमेल मेटाडेटा मध्ये 'कोरिलेशन आयडी' (correlation ID) वापरा. यामुळे विनंती (request), डिलिव्हरी आणि कन्फर्मेशन यांचा एकमेकांशी संबंध जोडला जातो.
विचारात घेण्यासारखे ट्रेडऑफ्स (Tradeoffs):
- इनबॉक्स पोलिंग (Inbox polling) हे मॉक्स (mocks) पेक्षा संथ असते.
- डिस्पोजेबल (disposable) पत्त्यांमध्ये फक्त नॉन-प्रोडक्शन डेटाच असावा.
- प्रिव्ह्यू एन्व्हायरनमेंटसाठी (Preview environments) क्लीनअप नियमांची आवश्यकता असते.
हे सोडू नका. सिस्टिम्समधील अंतरामध्ये (gaps) ईमेल फ्लो तुटतात. तिथेच मॉक्स (mocks) सर्वात कमकुवत ठरतात.