Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
यह शोध पत्र "टेस्ट ऑब्सेस्ड बाय मेथड" (Test Obsessed by Method) नामक एक नवीन टेस्ट स्मेल प्रस्तावित करता है, जो उन परीक्षणों की पहचान करता है जो एक ही प्रोडक्शन मेथड के कई निष्पादन पथों (execution paths) को कवर करते हैं, और पायथन स्टैंडर्ड लाइब्रेरी पर एक अनुभवजन्य अध्ययन के माध्यम से इसके पता लगाने की पुष्टि करता है जो यह दर्शाता है कि ऐसे परीक्षण अक्सर कई व्यवहारों को सत्यापित करते हैं और उन्हें अधिक केंद्रित इकाइयों में पुनर्गठित किया जा सकता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक खाद्य समीक्षक (food critic) के लिए एक टेस्टिंग मेनू तैयार कर रहे हैं। बेहतरीन खाना बनाने का सुनहरा नियम है: प्रत्येक व्यंजन में एक विशिष्ट स्वाद परोसें। यदि आप एक ही प्लेट में स्टेक, केक का एक टुकड़ा और आइसक्रीम का एक स्कूप मिलाकर परोसते हैं, तो समीक्षक भ्रमित हो जाएगा। वे यह नहीं समझ पाएंगे कि स्टेक कच्चा है, केक बहुत मीठा है, या आइसक्रीम पिघल रही है। यदि कुछ गलत होता है, तो उन्हें यह पता नहीं चलेगा कि भोजन के किस हिस्से को दोष दिया जाए।
सॉफ्टवेयर की दुनिया में, "व्यंजन" टेस्ट (tests) हैं, और "स्वाद" व्यवहार (behaviors) हैं (सॉफ्टवेयर को क्या करना चाहिए)।
यह शोध पत्र, जिसका शीर्षक है "Test Behaviors, Not Methods!", यह तर्क देता है कि कई सॉफ्टवेयर टेस्ट वर्तमान में उसी अव्यवस्थित मिश्रित प्लेट की तरह परोसे जा रहे हैं। लेखक, आंद्रे होरा और एंडी ज़ैडमैन, इन भ्रमित करने वाले टेस्टों को पहचानने का एक नया तरीका पेश करते हैं, जिसे वे "Tests Obsessed by Methods" कहते हैं।
इन सरल उपमाओं का उपयोग करके उनकी खोज का विवरण यहाँ दिया गया है:
1. पुराना तरीका: सामग्रियों की गिनती करना
पहले, विशेषज्ञ इन अव्यवस्थित टेस्टों को खोजने के लिए केवल इस बात की गिनती करते थे कि एक टेस्ट ने कोड को कितनी बार "छुआ"। वे सोचते थे, "यदि एक टेस्ट प्रोडक्शन कोड को 3 या अधिक बार कॉल करता है, तो यह शायद बहुत कुछ करने की कोशिश कर रहा है।"
लेखक इस पद्धति को "Eager Test" की गंध (smell) कहते हैं। हालाँकि, उन्होंने पाया कि यह विधि केवल चम्मचों की संख्या गिनकर भोजन का न्याय करने के समान है। यह सटीक नहीं है। एक टेस्ट सीन सेट करने के लिए कई बार एक फंक्शन को कॉल कर सकता है, बिना वास्तव में अलग-अलग स्वादों का परीक्षण किए। यह समस्या खोजने का एक अनाड़ी तरीका है।
2. नया विचार: फिल्म देखना (रनटाइम विश्लेषण)
केवल चम्मचों की गिनती करने के बजाय, लेखक सुझाव देते हैं कि टेस्ट के चलते समय उसकी "फिल्म" देखें। वे एक नया नियम प्रस्तावित करते हैं: यदि एक एकल टेस्ट किसी कोड के टुकड़े को फिनिश लाइन तक पहुँचने के लिए कई अलग-अलग "रास्ते" (paths) लेने के लिए मजबूर करता है, तो वह टेस्ट "ऑब्सेस्ड" (obsessed) है।
एक प्रोडक्शन मेथड (कोड का एक टुकड़ा) को एक भूलभुलैया (maze) के रूप में सोचें।
- अच्छा टेस्ट: आप एक छोर चेक करने के लिए भूलभुलैया में एक खोजकर्ता भेजते हैं कि क्या बायां दरवाजा काम करता है। फिर आप दूसरा खोजकर्ता भेजते हैं ताकि यह जांचा जा सके कि क्या दायां दरवाजा काम करता है। स्पष्ट और केंद्रित।
- ऑब्सेस्ड टेस्ट: आप एक ऐसा खोजकर्ता भेजते हैं जो पहले बाएं दरवाजे से जाता है, फिर वापस आता है, दाएं दरवाजे से दौड़ता है, और फिर एक ही बार में गुप्त सुरंग को भी आजमाता है।
लेखक इसे "Test Obsessed by Method" कहते हैं। यह टेस्ट "लालची" है क्योंकि यह एक ही बार में एक ही भूलभुलैया के हर संभावित पथ को कवर करने की कोशिश करता है, बजाय इसके कि काम को विभाजित किया जाए।
3. प्रयोग: पायथन लाइब्रेरी की जाँच करना
यह देखने के लिए कि क्या यह "जुनून" (obsession) एक वास्तविक समस्या है, लेखकों ने पायथन स्टैंडर्ड लाइब्रेरी (पूर्व-लिखित कोड का एक विशाल संग्रह जिसका उपयोग लाखों डेवलपर्स करते हैं) में एक खोज अभियान चलाया।
उन्होंने 2,054 टेस्ट्स की जाँच की। यहाँ उन्हें क्या मिला:
- खोज: उन्हें 44 टेस्ट्स मिले जो "ऑब्सेस्ड" थे। ये टेस्ट एक ही फंक्शन के कई अलग-अलग परिणामों की जांच करने की कोशिश कर रहे थे।
- फैलाव: ये अव्यवस्थित टेस्ट उनके द्वारा जांचे गए 12 में से 11 अलग-अलग लाइब्रेरी में पाए गए। यह कोई दुर्लभ त्रुटि नहीं है; यह एक सामान्य आदत है।
- समाधान: औसतन, प्रत्येक इन 44 अव्यवस्थित टेस्ट्स में वास्तव में दो अलग-अलग काम करने की कोशिश की जा रही थी। यदि उन्हें विभाजित कर दिया जाता, तो वे 44 टेस्ट 118 साफ और केंद्रित टेस्ट बन सकते थे।
- "अहा!" क्षण: लगभग 23% इन अव्यवस्थित टेस्ट्स में, प्रोग्रामरों ने वास्तव में टिप्पणियों (comments) में स्वीकार किया था, "हे, हम यहाँ दो अलग-अलग चीजों का परीक्षण कर रहे हैं!" वे जानते थे कि यह अव्यवस्थित है लेकिन फिर भी उन्होंने ऐसा किया।
4. यह क्यों मायने रखता है?
लेखकों का तर्क है कि जब एक टेस्ट एक साथ बहुत सारे पथों को कवर करने की कोशिश करता है:
- इसे समझना कठिन है: उस मिश्रित प्लेट की तरह, आप यह नहीं बता सकते कि आप कौन सा स्वाद चख रहे हैं।
- यह नाजुक (fragile) है: यदि आप "बाएं दरवाजे" के लिए कोड बदलते हैं, तो आप अनजाने में "दाएं दरवाजे" के टेस्ट को भी तोड़ सकते हैं, भले ही वे असंबंधित हों।
- इसे ठीक करना कठिन है: जब कोई टेस्ट विफल होता है, तो आपको यह पता नहीं चलता कि कौन सा विशिष्ट व्यवहार टूट गया है।
मुख्य निष्कर्ष
यह पेपर यह दावा नहीं करता कि यह परीक्षण की हर समस्या को हल करता है। इसके बजाय, यह एक नया, अधिक सटीक उपकरण (केवल गिनती के बजाय रनटाइम विश्लेषण का उपयोग करके) प्रदान करता है ताकि उन टेस्ट्स को पहचाना जा सके जो एक ही कोड के टुकड़े के साथ बहुत कुछ करने की कोशिश कर रहे हैं।
वे सुझाव देते हैं कि यदि एक टेस्ट किसी फंक्शन को कई अलग-अलग पथों पर चलने के लिए मजबूर करता है, तो उसे विभाजित किया जाना चाहिए। ठीक वैसे ही जैसे एक शेफ को स्टेक, केक और आइसक्रीम अलग-अलग प्लेटों पर परोसना चाहिए, एक डेवलपर को भी हर विशिष्ट व्यवहार के लिए अलग-अलग टेस्ट लिखने चाहिए।
संक्षेप में: अपने टेस्ट के साथ लालची न बनें। एक समय में एक व्यवहार, एक पथ, एक स्वाद का परीक्षण करें।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।