कार्यवृत्त पार्सिंग फ़िक्स्चर जो काम आते रहें

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

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

सीवी का कोई मानक प्रारूप क्यों नहीं है?

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

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

पूरी परीक्षण रणनीति इसी आधार पर टिकी है। लक्ष्य प्रारूप का पालन नहीं है, क्योंकि पालन करने लायक कोई प्रारूप है ही नहीं। लक्ष्य ऐसे दस्तावेज़ों से सही फ़ील्ड निकालना है जिनका लेआउट कोई नियंत्रित नहीं करता।

पार्सिंग टेस्ट किन लेआउट रूपों को कवर करें?

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

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

फ़िक्स्चर को परिदृश्य से व्यवस्थित करें या संख्या से?

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

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

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

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

अनियमित जनरेशन विफलताओं को दोहराने लायक क्यों नहीं छोड़ता?

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

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

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

फ़िक्स्चर कैसे पुराने पड़ जाते हैं?

धीरे-धीरे, और तीन ढंगों से जो इसलिए आसानी से छूट जाते हैं क्योंकि हर एक बिल्कुल कुछ नहीं जैसा दिखता।

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

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

डेवलपर्स के लिए: फ़िक्स्चर का आकार और अपेक्षित फ़ील्ड

इनपुट और अपेक्षा साथ रखिए, और अपेक्षा संकरी रखिए।

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

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

जो कुछ भी किसी फ़िक्स्चर में रहता है वह इसी काम के लिए गढ़ा गया होना चाहिए। यहाँ बताए गए नमूना दस्तावेज़ और अपेक्षित फ़ील्ड ऐसे गढ़े हुए नमूने हैं जिनमें किसी असली सीवी से ली गई कोई सामग्री नहीं है, और वे पार्सिंग तर्क को चलाने के लिए हैं, किसी का प्रतिनिधित्व करने के लिए नहीं।

आगे के कदम

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