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