इकाई परीक्षण की कला

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

इसी तरह, हम आमतौर पर इकाई परीक्षण के अध्ययन से संबंधित हैं। आखिरकार, यूनिट परीक्षण रॉकेट विज्ञान नहीं हैं; उनके अध्ययन में तैयारी के वर्षों की आवश्यकता नहीं होती है और यूनिट परीक्षण गुरुओं से मोटी "टैल्मड्स" का अध्ययन करने में कई रातों की नींद हराम हो जाती है। स्वचालित कोड परीक्षण की अवधारणा को 10 मिनट में समझाया जा सकता है, और जब आप एक एक्सयूनिट टेस्ट फ्रेमवर्क (एक और 15 मिनट) से परिचित हो जाते हैं, तो आप लगभग तुरंत किसी भी अन्य ढांचे के साथ काम कर सकते हैं। फिर आपको किसी अन्य प्रकार के अलगाव ढांचे का अध्ययन करने के लिए एक और 20 मिनट खर्च करने की आवश्यकता होगी, जैसे राइनो मोक्स, और वॉइला, हमारे पास इकाई परीक्षणों के क्षेत्र में एक और पेशेवर है।


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

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

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

शुरुआत से ही, रॉय पाठक के सिर में एक महत्वपूर्ण विचार को अंकित करने की कोशिश कर रहा है: उच्च-गुणवत्ता वाले परीक्षण उच्च-गुणवत्ता वाले उत्पादन कोड से कम महत्वपूर्ण नहीं हैं! अच्छे परीक्षणों के स्तंभों का पूरा अध्याय 7 अच्छे परीक्षणों के लिए समर्पित है, लेकिन अपनी सीमाओं से परे, "अच्छे" परीक्षणों की छाया पाठक को लगातार परेशान करेगी। संभवतः दर्जनों पुस्तकों और अनगिनत लेखों में कोड की गुणवत्ता के बारे में लिखा गया है; हम सभी जानते हैं कि कोड लिखना कितना महत्वपूर्ण है, जिसे बनाए रखना आसान है और इसकी गुणवत्ता को बेहतर बनाने के लिए क्या करना चाहिए। लेकिन परीक्षणों की गुणवत्ता के लिए हमारा दृष्टिकोण अक्सर इतना सार्थक नहीं होता है, हालांकि खराब परीक्षण आपके जीवन को व्यापार तर्क में $ # ओ-कोड से भी बदतर बना सकते हैं।

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

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

नोट
आप "आदर्श आर्किटेक्चर" लेख में खराब डिज़ाइन के "लिटमस टेस्ट" के रूप में यूनिट परीक्षणों का उपयोग करने के बारे में अधिक पढ़ सकते हैं ।

खुद रॉय के अनुसार, उन्होंने एक किताब लिखने में 3 साल बिताए - और यह उनके दो बच्चों जे "बनाने" पर खर्च होने से अधिक है और यह समय-समय पर महसूस किया जाता है। उदाहरण के लिए, पुस्तक में अलग-अलग जगहों पर वर्ग आरेखों का एक अलग प्रारूप उपयोग किया जाता है, कभी-कभी परीक्षण कक्षाओं और विधियों के नाम में अंतर होता है, और वास्तव में, deja vu सनसनी समय-समय पर दौरा करती है। अन्य मामूली बिंदु हैं। इसलिए, दो सौ पृष्ठों के लिए, लेखक NUnit लाइब्रेरी स्टेटमेंट के मानक सिंटैक्स का उपयोग करता है, और 200 वें पेज से, वह अचानक Assert.That का उपयोग करना शुरू कर देता है और घोषणा करता है कि यह सिंटैक्स अधिक घोषणात्मक है। जाहिर है, किताब पर काम शुरू होने के करीब डेढ़ साल बाद, रॉय को इस सिंटैक्स की जानकारी मिली, जो उन्हें पसंद आया, और पिछले उदाहरणों को बदलने के लिए अधिक समय और प्रयास नहीं था।

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

आप अन्य बिंदुओं को पा सकते हैं जिसमें आपकी राय लेखक की राय से भिन्न होगी, लेकिन सामान्य तौर पर, "द आर्ट ऑफ़ यूनिट टेस्टिंग" पुस्तक यूनिट परीक्षण के बारे में जानकारी का सबसे अच्छा स्रोत है, जो या तो आपके विश्वदृष्टि को सही दिशा में बदल सकती है, या संक्षेप और मौजूदा ज्ञान संरचना।

रेटिंग: ४+

संबंधित कड़ियाँ

किताबें

रॉय ओशेरोव द्वारा द आर्ट ऑफ़ यूनिट टेस्टिंग
xUnit टेस्ट पैटर्न: जेरार्ड मेस्जारोस द्वारा परीक्षण कोड को फिर से भरना
माइकल पंख द्वारा विरासत कोड के साथ प्रभावी ढंग से काम करना
^एन # एनटिट के साथ सी # में व्यावहारिक इकाई परीक्षण, एंडी हंट और डेव थॉमस द्वारा 2 ^{एन डी} संस्करण

पॉडकास्ट

केंट बेक के साथ JUnit का इतिहास और परीक्षण का भविष्य
केंट बेक, डेवलपर परीक्षण