चेकआउट पता फ़ॉर्म — टेस्ट केस जो रखने योग्य हैं

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

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

ये वही फ़ॉर्म हैं जो उपयोगकर्ता असल में भरते हैं

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

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

अनिवार्य और वैकल्पिक फ़ील्ड के टेस्ट केस

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

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

बिना पोस्टल कोड वाले देश को भी शुरू से आख़िर तक परखें। ऑर्डर पूरा होना संभव होना चाहिए, और पुष्टि में खाली पोस्टल कोड की पंक्ति नहीं दिखनी चाहिए।

देश बदलने पर क्या होता है?

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

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

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

क्या पेस्ट और ऑटोफ़िल अब भी काम करते हैं?

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

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

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

फ़ोन पर और धीमे कनेक्शन के साथ टेस्टिंग

मोबाइल लेआउट बदल देते हैं कि उपयोगकर्ता कहां तक पहुंच सकता है। कम चौड़ाई पर चलाने योग्य केस — देश चुनने वाला नियंत्रण खुलता है और बंद किया जा सकता है; कीबोर्ड उस फ़ील्ड को नहीं ढकता जिसमें टाइप हो रहा है या जमा करने वाला बटन को नहीं; उपप्रभाग की सूची लंबी होने पर खोजी या स्क्रॉल की जा सकती है; और त्रुटि संदेश फ़ील्ड से दूर स्क्रॉल किए बिना दिखता है।

धीमा या बाधित कनेक्शन भी जोड़ें। ऑर्डर जमा करें, जवाब बीच में रोकें, दोबारा जमा करें। फ़ॉर्म को बटन चालू रहने की वजह से दो ऑर्डर नहीं बनाने चाहिए, और अनुरोध विफल होने पर डाला गया पता खोना नहीं चाहिए। सहेजे पते वाले रास्ते के साथ भी वही व्यवहार चाहिए — कोई सहेजा पता संपादित करें, संपादन छोड़ दें, और पुष्टि करें कि मूल जैसा था वैसा ही है।

डेवलपर्स को क्या जांचना और क्या सीड करना चाहिए?

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

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

अंत में, टेस्ट ऑर्डर को वातावरण में ही टेस्ट ऑर्डर के रूप में चिह्नित करें। जो टेस्ट ऑर्डर असली जैसा दिखता है, वह देर-सबेर पूरा भी कर दिया जाएगा, और किसी टेस्ट के लिए बनाया गया पता डिलीवर करने योग्य पता नहीं होता।

आगे के कदम

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