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