पता टेस्ट डेटा — ऐसे फ़िक्स्चर जो टिके रहें

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

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

देशों से नहीं, परिदृश्यों से शुरुआत करें

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

पहले परिदृश्य के हिसाब से लगाएं और हर परिदृश्य के भीतर देश नोट करें। एक काम चलाने योग्य शुरुआती सेट इस तरह दिखता है।

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

पता फ़िक्स्चर दोहराने योग्य क्यों होने चाहिए?

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

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

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

असली ग्राहक के पते यहां क्यों नहीं आने चाहिए

प्रोडक्शन के पते किसी टेस्ट या स्टेजिंग वातावरण में नकल करना इस क्षेत्र की सबसे आम डेटा-संरक्षण गलती है, और यह समझना आसान है कि लोग इसे क्यों करते हैं — डेटा यथार्थवादी है, वह वहां पहले से है, और किसी को कवरेज के बारे में सोचना ही नहीं पड़ता।

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

काल्पनिक डेटा इस दुविधा को हटा देता है। वह आकार में यथार्थवादी होता है, वह किसी का पता नहीं होता, और उसे बेझिझक प्रकाशित, साझा, जमा और दोबारा बनाया जा सकता है।

काल्पनिक डेटा को ईमानदार कैसे रखें?

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

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

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

डेवलपर्स के लिए: आकार, अलगाव और समीक्षा

फ़िक्स्चर को रिपॉज़िटरी में डेटा के रूप में रखें, ऐसे कोड के रूप में नहीं जो डेटा बनाता है। फ़ाइल में रखे मान तुलनीय, समीक्षा योग्य और खोजे जाने योग्य होते हैं; किसी टेस्ट सहायक के भीतर कॉलों की श्रृंखला से बने मान इनमें से कुछ भी नहीं होते, और जब कोई फ़िक्स्चर बदलता है तो समीक्षा में किसी को दिखता ही नहीं।

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

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

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

आगे के कदम

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