ईमेल सत्यापन टेस्टिंग: वे फ़्लो जो चुपचाप टूटते हैं

ईमेल सत्यापन टेस्टिंग साइनअप फ़्लो का वह हिस्सा है जिसे ज़्यादातर टीमें एक बार, सब कुछ ठीक चलने वाले रास्ते पर, आज़मा लेती है और फिर उसे पूरा मान लेती है। दिलचस्प नाकामियां कहीं और रहती हैं: दो बार खोला गया लिंक, किसी दूसरे ब्राउज़र में खोला गया लिंक, ऐसा कोड जो उपयोगकर्ता के पहले ही सत्यापित हो जाने के बाद आता है, ऐसा संदेश जो आता ही नहीं। यह लेख सत्यापन फ़्लो की असली अवस्थाएं और हर अवस्था में जांचने लायक मामले सामने रखता है।

सत्यापन फ़्लो किन अवस्थाओं से गुज़रता है

टेस्ट लिखने से पहले अवस्थाएं लिख लें। जिस फ़्लो को सिर्फ़ सत्यापित या असत्यापित कहकर बताया जाए, वह कम से कम चार अलग हालात छिपा रहा होता है, और हर हालात का अपना सही व्यवहार होता है।

ज़्यादातर ख़ामियां अवस्थाओं में नहीं, बल्कि एक अवस्था से दूसरी में जाने के पलों में रहती हैं। पूछें कि क्या होता है जब उपयोगकर्ता पहला संदेश अब भी रास्ते में होते हुए दूसरा मांगता है, या पुराने पते पर साइन इन रहते हुए नए पते की पुष्टि कर देता है।

पुष्टि लिंक दो बार खोलने पर क्या टूटता है?

कुछ नहीं टूटना चाहिए, और ठीक इसीलिए इसे जांचना ज़रूरी है। पुष्टि लिंक ऐसे रास्ते से पहुंचता है जो पूरी तरह उपयोगकर्ता के नियंत्रण में नहीं होता: मेल क्लाइंट लिंक का पूर्वावलोकन करते हैं, सुरक्षा स्कैनर उन्हें खोलते हैं, और उपयोगकर्ता जल्दबाज़ी में दूसरी बार क्लिक कर देते हैं।

चाहिए यह कि पहला मान्य उपयोग फ़्लो को ख़त्म कर दे और उसके बाद का हर उपयोग साफ़, हानिरहित नतीजा दे — यह पता चलने वाला पेज कि सत्यापन पहले हो चुका है, या साइन इन का निमंत्रण — न कि ऐसी ग़लती जिसे उपयोगकर्ता समझ ही न सके। जो नहीं चाहिए वह यह है कि दूसरा सत्यापन पासवर्ड बदल दे, सत्र फिर से बना दे, या ऐसा संदेश दिखाए जिससे लगे कि अकाउंट बिगड़ गया है।

एक जुड़ा हुआ मामला है जो टीमों को चकमा दे जाता है: दो अकाउंट, एक पता। अगर आपका प्रोडक्ट एक ही पता दो अकाउंट पर रखने देता है, तो एक पुष्टि संदेश को दोनों सत्यापित नहीं कर पाना चाहिए। इसे जानबूझकर जांचें।

पता बदलने और रीसेट के रास्तों की टेस्टिंग

पता बदलना और पासवर्ड रीसेट करना वही मशीनरी दोबारा इस्तेमाल करते हैं, पर नतीजा अलग होता है, और ठीक वहीं साझा कोड टपकने लगता है।

जब उपयोगकर्ता पता बदलता है, तब कुछ समय के लिए दोनों पते मौजूद रहते हैं। पुराने पते से अकाउंट वापस पाना अब भी संभव रहना चाहिए, और नया पता तब तक लागू नहीं होना चाहिए जब तक वह साबित न हो जाए। जब उपयोगकर्ता पासवर्ड रीसेट करता है, तब वही पुष्टि सत्यापन का काम भी नहीं करनी चाहिए, और उलटा भी। इन रास्तों को जांचने का मतलब है यह देखना कि एक मक़सद के लिए बनाया गया टोकन दूसरे मक़सद में ठुकराया जाता है — यह एक छोटा-सा एसर्शन है जो बग की एक बड़ी पूरी श्रेणी रोक देता है।

इस काम के लिए काम का फिक्स्चर वह इनबॉक्स है जिसे कोई दूसरा केस इस्तेमाल न कर रहा हो, ताकि जो संदेश आप खोलते हैं वह पक्का वही हो जिसे अभी-अभी फ़्लो ने भेजा। टेम्प मेल टूल ठीक इसी तरह का पता बनाता है, और एंड-टू-एंड सूट में OTP टेस्टिंग वाला लेख बताता है कि कोड आ जाने के बाद उसे निकालना कैसे है।

मेल कभी न आए तो क्या होना चाहिए?

यही वह रास्ता है जिसे टीमें छोड़ देती हैं, और उपयोगकर्ताओं से सबसे ज़्यादा मिलने वाला भी यही है, क्योंकि मेल ऐसी वजहों से नाकाम होती है जो किसी के नियंत्रण में नहीं: पते में कोई अक्षर ग़लत टाइप हो जाना, कोई सेवा जो संदेश चुपचाप हटा दे, कोई भेजने वाला जिस पर कुछ देर के लिए अंकुश लगा हो।

फ़्लो को न आना एक सामान्य नतीजा मानना चाहिए। उपयोगकर्ता बिना किसी बेतुकी देर के दूसरा संदेश मांग सके, इंटरफ़ेस साफ़-साफ़ बताए कि संदेश आने में थोड़ा समय लग सकता है, और अकाउंट ऐसी हालत में न छूटे जहां वह दोबारा न मांग सके क्योंकि कोई अनुरोध पहले से लंबित है। यहां कोई ख़ास संख्या या कोशिश तय नहीं है; बात बस इतनी है कि डिज़ाइन के पास इसका जवाब कहीं है।

फेंकने वाले इनबॉक्स से कोड पढ़ना

जब कोई फ़्लो लिंक के बजाय छोटा कोड भेजता है, तो टेस्ट को संदेश से वह कोड चाहिए। उसे उसी रन के लिए बनाए गए इनबॉक्स से पढ़ने से एसर्शन सीमित रहता है: जो संदेश मिलता है वह सिर्फ़ उसी केस का हो सकता है जो चल रहा है, जिससे ग़लत वजह से पास हो चुके टेस्ट की सबसे आम जड़ हट जाती है।

इससे असली इनबॉक्स भी टेस्ट से पूरी तरह बाहर रहते हैं। किसी साथी का पता कभी आपके रिग्रेशन सूट का पाने वाला नहीं होना चाहिए, इसलिए भी कि उन्हें वह ट्रैफ़िक मिलेगा, और इसलिए भी कि तब आपके एसर्शन ऐसे इनबॉक्स पर निर्भर हो जाएंगे जो आपके नियंत्रण में नहीं।

डेवलपर्स के लिए: टोकन, इडेम्पोटेंसी और वह रास्ता जो नहीं चलता

फ़ॉर्म नहीं, टोकन का मॉडल बनाइए। तीन गुण अलग से जांचे जाने लायक हैं।

पहला है एक बार का उपयोग। टोकन एक ही बार खर्च होना चाहिए, और दूसरी कोशिश का नतीजा सर्वर की ग़लती नहीं, बल्कि बेज़रर होना चाहिए। जहां यह बदलाव कुछ असरदार बदलता है, वहां कार्रवाई को इडेम्पोटेंट बनाएं ताकि दोहराव का नतीजा वही अंतिम हालत हो, कोई दूसरा असर नहीं।

दूसरा है समाप्ति। समाप्त हो चुके टोकन आपके लॉग में और उपयोगकर्ता की नज़र में अमान्य टोकन से अलग दिखने चाहिए, क्योंकि इलाज अलग-अलग हैं: समाप्ति का मतलब है फिर से शुरू करें, अमान्य का मतलब हो सकता है कि ग़लत लिंक कॉपी हुआ। समाप्त टोकन को जो नहीं करना चाहिए वह यह है कि अकाउंट आधे-अधूरे बदलाव की हालत में छोड़ दे।

तीसरा है एक साथ आना। एक साथ दो क्लिक, या दो टैब में खोला गया एक लिंक, एक ही फ़्लो को दो बार सत्यापित नहीं कर पाना चाहिए। यह बटन का नहीं, डेटा परत का गुण है, इसलिए इसे धीरे-धीरे दो बार क्लिक करके नहीं, बल्कि दोनों अनुरोध एक साथ भेजकर जांचें।

आख़िर में, फिक्स्चर और नोट्स में सीमा साफ़ रखें: ये पते थोड़ी देर के लिए टेस्ट मेल पाने के लिए हैं, ये असली पहचान नहीं हैं, और किसी फिक्स्चर से यह जताना नहीं चाहिए कि वे हैं।

अगले क़दम

अभी-अभी जारी किए गए सत्यापन फ़्लो को लेकर ऊपर की अवस्था तालिका पर चलिए और उन संक्रमणों पर निशान लगाइए जिन्हें आपने सचमुच जांचा है। फिर जो बच गए हों उन्हें चलाइए, हर केस के लिए टेम्प मेल पेज से नया बनाया गया पता इस्तेमाल करके। अगर कोई बड़ा लॉन्च तैयार हो रहा है, तो ट्रांजैक्शनल ईमेल टेस्टिंग चेकलिस्ट उस आसपास की मेल को कवर करती है जो सत्यापित अकाउंट को मिलने लगेगी।