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