यूनिट टेस्टिंग का ज़ेन

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

कैरियर की शुरुआत

मुझे यूनिट परीक्षण क्यों लिखना चाहिए?

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

क्या परीक्षण करें?

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

Mittelspiel

केवल एक चीज का परीक्षण करें

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

तर्क से बचें

डेवलपर्स के लिए परीक्षण में कीड़े सबसे कठिन चीजें हैं। जैसे ही आपने अपने परीक्षण में तर्क जोड़ने का फैसला किया, आपके टेस्ट कोड में बग आने की संभावना बढ़ जाती है। इसे पढ़ना, समझना और बनाए रखना कठिन हो जाता है। एक परीक्षण में switch और अन्य परिचालकों के for , foreach , का उपयोग करना भी एक कोड गंध हो सकता है जिसे आप एक से अधिक चीजों का परीक्षण कर रहे हैं।

एएए

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

नामकरण सम्मेलन के लिए छड़ी

टेस्ट के नाम वर्णनात्मक और समझने योग्य होने चाहिए न केवल इसके लेखक के लिए। बहुत सारी परीक्षण नामकरण रणनीतियाँ हैं, लेकिन मुझे रॉय ओशेरोव की एक पसंद है: [MethodName_StateUnderTest_ExpectedBehavior] । यह स्वरूपित तरीके से परीक्षण के बारे में सभी आवश्यक जानकारी है। किसी भी डेवलपर के लिए इस रणनीति का पालन करना आसान है।

उदाहरण:

 public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () public void Sum_simpleValues_Calculated () public void Parse_OnEmptyString_ExceptionThrown() public void Parse_SingleToken_ReturnsEqualTokenValue () 

लेकिन ध्यान दें कि आपके पास नामकरण सम्मेलन हो सकता है जिसे आपको अपनी वर्तमान परियोजना पर चलना होगा। उन्हें मिश्रण मत करो।

डेटा की तैयारी का परीक्षण करें

परीक्षण डेटा का निर्माण आपके परीक्षण कोड में गड़बड़ी और पीड़ा ला सकता है। आप इस स्थिति का सामना कर सकते हैं जब:

• आपको अपने मॉडल के कंस्ट्रक्टर को कोड के प्रत्येक टुकड़े में बदलना होगा, जहां यह मॉडल बनाया गया है (यह आमतौर पर तब होता है जब आपका मॉडल अपरिवर्तनीय होता है) ;
• आपके पास अपने परीक्षण डेटा का निर्माण करते समय बहुत सारे कोड डुप्लिकेट होते हैं;
• आपको अपने मॉडल कंस्ट्रक्टर में "मैजिक डेटा" का एक बहुत कुछ पास करना होगा (उदाहरण के लिए new Device("Stub", 10, true, "http"); ) ;
• आपको लगता है कि आपको एक प्रकार का यादृच्छिक डेटा जनरेटर बनाने की आवश्यकता है;
• आपके लिए परीक्षण डेटा संग्रह बनाना मुश्किल है।

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

यादृच्छिक डेटा का उपयोग न करें, क्योंकि आपका परीक्षण कुछ प्रकार के मूल्यों के प्रति संवेदनशील हो सकता है। नतीजतन आप अपने परीक्षण में बुराई हेइसेनबग प्राप्त कर सकते हैं जिसे ढूंढना और पुन: उत्पन्न करना मुश्किल है।

अपने परीक्षण ढांचे को जानें

अपने परीक्षण ढांचे की सभी विशेषताओं, अभिकथनों और अन्य विशेषताओं को जानें। यह आपको अपने परीक्षणों को अधिक पठनीय और सुरुचिपूर्ण बनाने में मदद करता है। उदाहरण के लिए NUnit ढांचे में आप दो अभिकथन मॉडल का उपयोग कर सकते हैं और आप वह चुन सकते हैं जिसे आप सबसे अधिक पसंद करते हैं:

 Assert.AreEqual(StatusCode.OK, response.StatusCode); 

या

 Assert.That(StatusCode.OK, Is.EqualTo(response.StatusCode)); 

सेटअप और फाड़ के तरीकों, टेस्टकेस और श्रेणी विशेषताओं, संग्रह के बारे में मत भूलना। मुखरता में अपेक्षित और वास्तविक परिणाम मापदंडों को भ्रमित न करें।

Endspiel

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

यूनिट टेस्टिंग एक बहुत बड़ा दर्शन है जिसकी चर्चा सिर्फ एक पोस्ट में नहीं की जा सकती। यहां मैंने यूनिट परीक्षण से संबंधित सामान्य दृष्टिकोण और लगातार प्रश्नों को समझाया। यदि आप गहरा गोता लगाना चाहते हैं तो आपको यह लिंक दिलचस्प लग सकते हैं:

रॉय ओशेरोव ब्लॉग
रॉय ओशेरोव की पुस्तक, "द आर्ट ऑफ़ यूनिट टेस्टिंग"

शांत और इकाई परीक्षण रखें