टेस्ट फिक्स्चर पहचान डेटा: भरोसेमंद टेस्ट के लिए लोगों का डेटा कैसे सजाएं

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

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

जनरेटर के बजाय फिक्स्चर में क्या रखा जाना चाहिए?

फिक्स्चर तब इस्तेमाल होता है जब टेस्ट किसी तय नतीजे पर दावा करता है, और जनरेटर तब जब टेस्ट ऐसे इनपुट की खामियां ढूंढ रहा हो जिनके बारे में उसे पता नहीं। यह फ़र्क़ आकार या औपचारिकता का नहीं है; यह इस बात का है कि किसी को इनपुट पहले से जानना है या नहीं।

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

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

हर बार रैंडम चुनाव नाकामी को दोहराने लायक क्यों नहीं छोड़ता?

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

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

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

फिक्स्चर रिकॉर्ड के नाम और समूह कैसे बनाएं?

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

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

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

कौन से पहचान सीमा मामले स्थायी फिक्स्चर के लायक हैं?

एक छोटी सूची आश्चर्यजनक रूप से बड़ा हिस्सा कवर कर लेती है, क्योंकि हर प्रविष्टि किसी और मान को नहीं, किसी और धारणा को तोड़ती है।

आख़िरी प्रविष्टि ही सबसे ज़्यादा छोड़ी जाती है और सबसे ज़्यादा कीमती है। यही अकेला फिक्स्चर है जो उस समय फेल होता है जब कोई सुसंगतता नियम ग़लती से बंद कर दिया गया हो, और सुसंगतता के नियम ठीक उस क़िस्म का कोड होते हैं जिसे किसी घटना के दौरान ढीला कर दिया जाता है और फिर कभी कसा नहीं जाता।

फिक्स्चर सड़ते कैसे हैं और उसे क्या रोकता है?

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

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

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

क्या फिक्स्चर बनाए ही जाने चाहिए?

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

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

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

डेवलपर्स के लिए: फिक्स्चर सेट की बनावट

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

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

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

अगले कदम

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