पुष्टि वाला मेल साइनअप प्रवाह का वह हिस्सा है जिसे ब्राउज़र टेस्ट अकेले नहीं चला सकता। कोई न कोई एक पते का मालिक होना चाहिए, संदेश पाना चाहिए और कोड टेस्ट को लौटाना चाहिए। टेम्पररी मेलबॉक्स API ठीक यही करता है: सूट किसी सेवा से HTTP पर मेलबॉक्स बनाने को कहता है, जो आता है उसे पढ़ता है, और केस खत्म होने पर मेलबॉक्स फेंक देता है। न ब्राउज़र, न साझा इंसानी इनबॉक्स, और न हाथ से कॉपी-पेस्ट।
यह लेख उसी इंतज़ाम के API पक्ष के बारे में है। यह आपके ऐप्लिकेशन को लोकल रिसीविंग एंडपॉइंट की ओर मोड़ने के बारे में नहीं है — वह CI में ईमेल कैप्चर करना है, और दोनों अलग समस्याएं हल करते हैं। लोकल कैप्चर साबित करता है कि आपका ऐप्लिकेशन क्या भेजता है। मेलबॉक्स API साबित करता है कि असल में क्या पहुंचता है — असली डिलीवरी रास्ते से, उस पते पर जिसका मालिक टेस्ट है।
टेस्ट में मेलबॉक्स API क्यों इस्तेमाल करें?
क्योंकि विकल्प या तो असली इंसानी इनबॉक्स है, या कुछ नहीं।
साझा इनबॉक्स एक खराब फिक्स्चर है। कई रन एक ही इनबॉक्स पढ़ते हैं, पिछले रन के संदेश अब भी वहीं पड़े रहते हैं, और पता ऐसा ट्रैफ़िक जमा करता है जो किसी टेस्ट ने नहीं मांगा। फिर हर एसर्शन को अंदाज़ा लगाना पड़ता है कि कौन-सा संदेश मौजूदा केस का है, और अंदाज़े में ही अस्थिरता पैदा होती है।
किसी सेवा का वेब इंटरफ़ेस ब्राउज़र से खुरचना दूसरा खराब विकल्प है। यह टेस्ट को ऐसे मार्कअप पर निर्भर कर देता है जो बिना बताए बदल जाता है, सेशन स्थिति पर, और ऐसे लॉगिन पर जिसकी देखभाल सूट को करनी पड़ती है। जैसे ही सेवा कोई बटन नया रूप देती है, हरा सूट बिना किसी उत्पाद-संबंधी वजह के लाल हो जाता है।
मेलबॉक्स API दोनों समस्याएं हटा देता है। पता केस के लिए बनाया जाता है, वह स्वभाव से खाली होता है, और उसे ऐसे स्थिर इंटरफ़ेस से पढ़ा जाता है जिसे टेस्ट सीधे कॉल कर सकता है। सूट को अब इस बात से मतलब नहीं कि सेवा कैसी दिखती है, बस इससे कि अनुबंध टिके: बनाओ, पाओ, पढ़ो, हटाओ।
एक निजता का तर्क भी है। API से बना पता किसी का प्रतिनिधित्व नहीं करता। वह किसी व्यक्ति का इनबॉक्स नहीं है, वह ऐसी जगह नहीं है जहां कोई असली संदेश पहुंच सके, और वह रन के साथ फेंक दिया जाता है।
टेस्ट को असल में कौन-से एंडपॉइंट चाहिए?
मेलबॉक्स API दर्जनों रूट खोल सकता है, पर टेस्ट क्लाइंट को चार काम चाहिए, और उन्हें वैसे नाम देना मदद करता है जैसे सूट उन्हें इस्तेमाल करेगा।
बनाना एक पता और एक हैंडल लौटाता है। पता वह है जिस पर टेस्ट के नीचे वाले ऐप्लिकेशन को भेजने को कहा जाता है। हैंडल, जो अक्सर टोकन या पहचानकर्ता होता है, वह है जिससे टेस्ट हर बाद की कॉल में उस इनबॉक्स के बारे में पूछता है। सूट को दोनों को एक ही ऑब्जेक्ट मानना चाहिए और हैंडल को पते से कभी दोबारा नहीं बनाना चाहिए, क्योंकि सेवाएं इन दोनों को बेमेल रखने के लिए आज़ाद हैं।
सूची बॉडी के बजाय सारांश लौटाती है: हर संदेश के लिए एक प्रविष्टि, पहचानकर्ता, भेजने वाले, विषय और पहुंचने के समय के साथ। यही वह कॉल है जिसे पोलिंग लूप को इस्तेमाल करना चाहिए, क्योंकि यह सस्ती है और शुरुआत में मायने रखने वाले एक ही सवाल का जवाब देने के लिए काफी है: क्या अब तक कुछ आया भी है।
पढ़ना एक संदेश पूरा लौटाता है, टेक्स्ट और HTML हिस्सों समेत। कोड वहीं रहता है, और यह वह कॉल है जो सूची के मिलान की सूचना देने के बाद ही करनी चाहिए।
साफ़ करना किसी इनबॉक्स से संदेश हटाता है या इनबॉक्स पूरा मिटा देता है। टेस्ट को यह दो वजहों से चाहिए: नया पता बनाए बिना कोशिशों के बीच अवस्था रीसेट करने के लिए, और केस खत्म होने पर सफ़ाई के लिए।
कुछ सेवाएं एक प्रतीक्षा या लंबी-पोल एंडपॉइंट जोड़ती हैं, जो संदेश आने या समय-सीमा बीतने तक कनेक्शन थामे रखता है। यह सुविधाजनक है, पर क्लाइंट को फिर भी सूची पर लौट पाना चाहिए, क्योंकि प्रतीक्षा वाला कॉल ही सबसे ज़्यादा दर-सीमा में फंसता है।
बिना अस्थिरता के कोड पोल करना
इस तरह के टेस्ट में सबसे आम गलती है तय समय सोना। सेकंडों की एक स्थिर संख्या एक अंदाज़ा है: धीमी डिलीवरी पर बहुत कम, तेज़ डिलीवरी पर बेकार ज़्यादा, और भरी हुई CI मशीन पर दोनों दिशाओं में गलत। उसकी जगह ऐसा लूप रखें जो सूची कॉल करे, मिलान देखे और मिलते ही लौट आए, ऊपर की एक सीमा के साथ जो टेस्ट को फेल करे, जॉब को लटकाए नहीं।
मिलान समस्या का दूसरा आधा हिस्सा है। टेस्ट जिस संदेश को चाहता है वह उस पते पर भेजा गया है जो केस ने बनाया, और अगर इनबॉक्स में एक से ज़्यादा तरह के मेल रह सकते हैं तो वह जिसके विषय में कोई स्थिर टुकड़ा हो। सबसे नए मिलान को प्राथमिकता दें, ताकि दोबारा कोशिश से हुई दोहरी डिलीवरी पढ़ाई को न भ्रमित करे। पहला संदेश कभी बिना शर्त न लें; दोबारा इस्तेमाल किए गए पते पर पुराना कोड ठीक इसी तरह सत्यापित हो जाता है।
निकालना एंकरित होना चाहिए। एक बॉडी में संदर्भ संख्या, समय-चिह्न और कीमत हो सकते हैं, और पहली अंक-शृंखला पकड़ने वाला पार्सर कभी-कभी कोड की जगह इनमें से कुछ पकड़ लेता है। वह शब्दावली खोजें जो कोड पेश करती है, कोड को उसके आसपास से पढ़ें, और कुछ न मिलने पर बॉडी संलग्न करके फेल हों।
आखिर में, दोबारा भेजने की सीमा का सम्मान करें। कोड प्रवाह आम तौर पर छोटी खिड़की में कुछ ही भेजने की इजाज़त देता है, और यह सीमा खुद जांचे जा रहे व्यवहार का हिस्सा है। ताज़ा कोड के लिए बटन दोबारा दबाने वाला टेस्ट कभी न कभी मना कर दिया जाएगा और गलत वजह से फेल होगा। दोबारा कोशिश मेलबॉक्स फिर पढ़कर करें, नया संदेश भड़काकर नहीं।
इसे एंड-टू-एंड या CI सूट में जोड़ना
साफ़ शक्ल है एक फिक्स्चर। प्रवाह शुरू होने से पहले फिक्स्चर एक इनबॉक्स बनाता है और उसका पता लौटाता है। टेस्ट उस पते का इस्तेमाल करते हुए ऐप्लिकेशन चलाता है। ऐप्लिकेशन के भेजने की पुष्टि करने के बाद एसर्शन इनबॉक्स पढ़ता है और कोड निकालता है। केस खत्म होने पर फिक्स्चर इनबॉक्स हटा देता है।
क्लाइंट को छोटा और इंजेक्ट करने योग्य रखें। एक मॉड्यूल चारों कॉल लपेटता है; टेस्ट उस मॉड्यूल पर निर्भर करता है, सूट में बिखरे कच्चे HTTP पर कभी नहीं। इससे यूनिट टेस्ट में नकली लगाना संभव होता है और वही सूट एसर्शन दोबारा लिखे बिना किसी दूसरी सेवा पर मोड़ी जा सकती है।
CI में क्रेडेंशियल जॉब के सीक्रेट स्टोर में रहें, रिपॉज़िटरी में कभी नहीं और लॉग की एक पंक्ति में कभी नहीं। हर जॉब या हर समानांतर वर्कर को अपना इनबॉक्स दें, और बने हुए पतों के आगे कुछ ऐसा लगाएं जो रन पहचाने, ताकि भटका हुआ संदेश देखकर ही जिम्मेदार ठहराया जा सके। क्लाइंट का टाइमआउट जॉब के अपने टाइमआउट से नीचे रखें, ताकि अटका हुआ पोल साफ़ संदेश के साथ फेल हो, अचानक जॉब रद्द होने के बजाय।
पढ़ाई दोबारा करें, पूरा प्रवाह नहीं। अगर कोड अब तक नहीं आया तो रुकें और फिर पढ़ें; साइनअप दोबारा चलाने से दूसरा संदेश बनेगा और उसके साथ एसर्शन के लिए दूसरा उम्मीदवार भी। और मेलबॉक्स API को प्रोडक्शन प्रवाहों से बाहर रखें: यह टेस्ट इंफ्रास्ट्रक्चर है, और किसी सूट से कभी असली ग्राहक को भेजा नहीं जा सकना चाहिए।
कोड के आसपास का प्रवाह, न कि उसे पढ़ने की यांत्रिकी, ईमेल वेरिफिकेशन प्रवाह का टेस्ट में कवर है, और खास तौर पर पार्सिंग का चरण एंड-टू-एंड सूट में OTP टेस्टिंग का विषय है।
अलगाव और सफ़ाई
हर केस के लिए एक पता वह नियम है जो टेस्टों के बीच के ज़्यादातर फेल होने रोकता है। यह यह सोचने की ज़रूरत हटा देता है कि कौन-सा संदेश किसका है, और ताज़गी का सवाल गायब कर देता है, क्योंकि इनबॉक्स ने हमेशा एक ही केस का ट्रैफ़िक पाया है।
सफ़ाई स्पष्ट और बिना शर्त होनी चाहिए। इनबॉक्स को उस टियरडाउन में हटाएं जो केस पास हो या फेल, दोनों में चले, सिर्फ़ खुशहाल रास्ते पर नहीं। सिर्फ़ सेवा की उम्र पर भरोसा करना गलती है: संदेश इतनी देर तक रह सकता है कि उसी मशीन पर कोई बाद वाला रन उसे पढ़ ले, और वह उम्र एक सुविधा है, गारंटी नहीं।
अगर सफ़ाई फेल हो तो उसे लॉग करें और सूट को पूरा होने दें। सफ़ाई की गलती जानने लायक है, पर वह उत्पाद के दोष जैसी नहीं है, और उसके लिए रन फेल करना टीम को टियरडाउन की गलतियां नज़रअंदाज़ करना सिखाता है। पते ने जो कुछ पाया उसे टेस्ट डेटा मानें: वह एक एसर्शन के लिए है, उसे निर्यात या साझा नहीं करना चाहिए, और उसे कभी किसी का संपर्क बिंदु नहीं मानना चाहिए।
सीमाएं और चेतावनियां
मेलबॉक्स API फिर भी एक तीसरे पक्ष की निर्भरता है, और उसकी सीमाएं आपकी सीमाएं बन जाती हैं। प्रति मिनट दर-सीमाएं बड़े समानांतर रन से आए बनाने के झुंड को मना कर सकती हैं। कोटा तय करता है कि एक साथ कितने पते रह सकते हैं। संदेश देर से आ सकते हैं, और देर से आया संदेश आने तक बिल्कुल गुम संदेश जैसा दिखता है।
डिस्पोजेबल डोमेन भी व्यापक रूप से ब्लॉक होते हैं। किसी सेवा का डोमेन उसी साइनअप फ़ॉर्म से ठुकराया जा सकता है जिसे आप टेस्ट कर रहे हैं, और यह एक वैध टेस्ट को उलझाने वाली नाकामी में बदल देता है। जब ऐसा हो, तो जवाब सेवा के लिए अपवाद बनाना नहीं, बल्कि यह समझना है कि जांच के नीचे वाला उत्पाद डिस्पोजेबल पतों को जानबूझकर ठुकराता है या नहीं, और उस व्यवहार को जानबूझकर टेस्ट करना है।
ईमानदार सार यह है कि मेलबॉक्स API उस बात का दावा करने का सही औज़ार है जो पहुंचता है। यह दावा करने के लिए कि आपका ऐप्लिकेशन क्या भेजता है, लोकल रिसीविंग एंडपॉइंट तेज़ है और उस पर कोई कोटा नहीं। ज़्यादातर परिपक्व सूट दोनों इस्तेमाल करती हैं: बहुत सारे एसर्शन के लिए लोकल कैप्चर, और मेलबॉक्स API सिर्फ़ वहां जहां असली डिलीवरी रास्ता ही जांच की चीज़ हो।
अगले क़दम
अपने सूट में वह टेस्ट ढूंढें जो साझा इनबॉक्स पोल करके कोड पढ़ता है, और उसे ऐसे फिक्स्चर से बदलें जो मेलबॉक्स API से ताज़ा पता बनाता हो। पता रन के साथ लॉग करें, टियरडाउन में हटाएं, और देखें कि जो अस्थिरता आपने स्वीकार कर रखी थी, उसका कितना हिस्सा यूं ही बंद हो जाता है। जब हाथ से असली इनबॉक्स चाहिए हो, टेम्प मेल पेज पल भर में एक बना देता है, और वह जो पते देता है वे एक रन के लिए मचान हैं, कभी असली पहचान नहीं।