इकाई परीक्षण - व्यक्तिगत अनुभव

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



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







मैं तुरंत समझाता हूं - "अच्छी वास्तुकला" से मेरा मतलब है कि सिस्टम को कमजोर रूप से निर्भर मॉड्यूल (परतों) में विभाजित करना, जिसमें मॉड्यूल के अंदर परिवर्तन के बाद सिस्टम स्थिर रहता है।



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



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



लेकिन, इस तथ्य के बावजूद कि कुछ इकाई परीक्षण हैं, कोड किसी भी वर्ग या विधि के लिए तैयार है यदि आवश्यक हो तो परीक्षण किया जाए।



और यह ठीक है कि यह इच्छा इकाई परीक्षण लिखने की क्षमता के लिए है कि आवेदन की गुणवत्ता के लिए निचली रेखा निर्धारित करता है ।



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



विषय पर अधिक: लेख habrahabr.ru/blogs/development/51706



सारांश: कोड लिखें जैसे कि आप वास्तव में इसे यूनिट परीक्षणों के साथ कवर करने जा रहे थे :)