टीडीडी और यूनिट परीक्षणों के बारे में थोड़ा और

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



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

1. सरलीकृत कोड समर्थन

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

मैं परीक्षण लिखने की सलाह कभी नहीं दूंगा, क्योंकि आप अक्सर परीक्षण में गलती कर सकते हैं, और परीक्षण को छोड़ सकते हैं। मैं एक सार्वभौमिक विधि नहीं देखता हूं।

2. मॉड्यूल में संरचना का एक स्पष्ट विभाजन

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

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

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

3. लड़ाई की जटिलता

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

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

डेवलपर का लक्ष्य 100% परीक्षणों, या बिल्कुल 5% के साथ कोड को कट्टरता से कवर करने के लिए नहीं होना चाहिए, लेकिन एक जटिल समाधान बनाने के लिए, विकास के समय और गुणवत्ता के बीच संतुलन, परीक्षणों की उपलब्धता और उनकी अनुपस्थिति। मेरे गुल्लक में, परियोजनाएं लगभग 0 से 20% तक परीक्षणों से आच्छादित हैं, और मुझे परियोजना के मापदंडों पर स्पष्ट निर्भरता नहीं दिखाई देती है: लोगों की संख्या, विकास की अवधि या टीम में लोगों के फेरबदल। तुरंत एक आरक्षण करें कि एक टीम में लोगों की संख्या तीन से अधिक नहीं है (हम छोटी टीमों में काम करते हैं), और एक परियोजना की अवधि विकास के 2,000 मानव-घंटे से अधिक नहीं है।

4. एक विनिर्देश के रूप में परीक्षण

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

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

5. मनोविज्ञान

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

साधारण जलप्रपात यहां से नहीं हटेगा: यदि एल्गोरिथ्म एक ही बार में फिट हो जाता है, तो आपको पुनरावृति करने की आवश्यकता नहीं है। यदि नहीं, तो अन्य तरीकों का प्रयास करें।

प्लस परीक्षण आपको कोड में आत्मविश्वास महसूस करने की अनुमति देते हैं, और "काम - स्पर्श न करें" के सिद्धांत से छुटकारा पाने में मदद करते हैं। कोई भी नकारात्मक परिवर्तन तुरंत खुद को दिखाएगा।

निष्कर्ष

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



पहले से ही एक हब पर है:

• TDD पर हाल ही में अच्छे डिजाइन के प्रेरक के रूप में लेख http://habrahabr.ru/blogs/development/110909/
• शाप के रूप में 100% परीक्षण कवरेज http://habrahabr.ru/blogs/development/51706/
• मैं लेखक के साथ सहमत नहीं हूं कि आप उनके लिखे जाने के बाद परीक्षणों के बारे में भूल सकते हैं, लेकिन अन्यथा लेख अच्छा है http://habrahabr.ru/blogs/development/28923/
• और अन्य उपयोगी लेख