हम इस परियोजना का एक नया हिस्सा शुरू करने वाले हैं और यूनिट परीक्षण में बहुत रुचि नहीं लगती है (और ऐसा नहीं लगता कि उन्होंने टीडीडी का अनुभव किया है)। मेरा मानना है कि यह लगभग आवश्यक है और यह रखरखाव को अधिक आसान बनाता है। तो आपके विचार क्या हैं?क्या आप अपनी पेशेवर परियोजनाओं में यूनिट परीक्षण का उपयोग करते हैं?
धन्यवाद
Btw: यह एक भाषा नास्तिक सवाल फिर भी नई परियोजना जावा में है,।
हमारी परियोजनाओं पर बिल्कुल यूनिट परीक्षण का उपयोग किया जाता है। प्रत्येक वर्ग जो मस्तिष्क रहित गेटर्स और सेटर्स नहीं है, इकाई-परीक्षण है। आपके कोड के लिए कार्यात्मक परीक्षण होने से आपको चिंता के बिना वांछित करने में मदद मिलती है कि आप एक बार में 50 अलग-अलग चीजें तोड़ देंगे।
इकाई परीक्षण का एक और underrated पहलू यह है कि यह सतह के लिए एक एल्गोरिथ्म के पहलुओं की अनदेखी लाता है। मैंने ऑर्थोगोनल सरणी का उपयोग करके यूनिट परीक्षणों को लिखने और दोबारा लिखने में दो दिन बिताए क्योंकि हर बार जब मैं परीक्षण मामलों की सूची में आया था, तो मैंने तकनीक की अगुवाई में अनदेखी की गई समस्या का एक और आयाम खोजा।
हां। हम थोड़ी देर के लिए टीडीडी का उपयोग कर रहे हैं। किसी भी तरह टीडीडी हमारे ऊपर पाया गया है और बेहतर कोड गुणवत्ता प्राप्त करने के लिए हमें इस वृद्धिशील दृष्टिकोण को पसंद है। प्रारंभिक इनकार वक्र के बावजूद जहां आपको लगता है कि कोड को लिखते समय यह लगातार और प्रगतिशील यूनिट परीक्षण वाले विकास को धीमा कर देगा, कई तरीकों से कोड आवश्यक है। ब्रेकिंग परिवर्तनों को लिखना बहुत मुश्किल है क्योंकि प्रतिगमन परीक्षणों के ढांचे की वजह से वृद्धि हुई है। सही होने पर कोड अधिक मजबूत होता है और कोड में विश्वास और पूरी परियोजना में सकारात्मक प्रभाव पड़ता है।
लेखन इकाई परीक्षण आजकल केवल अभिजात वर्ग के लिए नहीं है। यह हर डेवलपर जिम्मेदारी होना चाहिए। बाद में कोड पर एक बग पाया जाता है जितना अधिक खर्च करने के लिए खर्च किया जाएगा और इसे खोजना कठिन होगा। यह आसानी से एक रखरखाव दुःस्वप्न बन जाता है। यूनिट परीक्षणों का मजबूत समर्थन होने से इस जोखिम को बहुत कम कर दिया जाता है।
एक अच्छी तरह से कॉन्फ़िगर किया गया निरंतर एकीकरण प्रणाली के साथ इकाई परीक्षण की शक्ति और TDD का मेल परियोजना के प्रारंभिक चरणों में समस्याओं का तेजी से खोज के लिए अनुमति देता है। एक दैनिक निर्माण भविष्य और लगभग निश्चित परेशानियों से बचने के लिए जरूरी है।
मुझे लगता है कि यूनिट परीक्षण केवल एक उपयोगी चीज़ से अधिक है, यह डेवलपर के जिम्मेदारी भी है। यदि आप कोड जारी करते हैं जो यूनिट परीक्षणों के वैध और व्यापक सेट को पास करने के लिए नहीं लिखा गया है, तो आप अपनी परियोजना में देरी कर सकते हैं, या किसी अन्य के पैकेज, कक्षाओं आदि में समस्याएं पैदा कर सकते हैं।
इसके अतिरिक्त, आपको अपने ग्राहक के साथ घनिष्ठ संपर्क में रहें (भले ही यह आपकी खुद की कंपनी हो), और उन्हें व्यापक स्वीकृति परीक्षण करने के लिए प्रयास करें और प्रोत्साहित करें। यह उनके सर्वोत्तम हितों में है (हालांकि मुझे पता चला है कि कुछ कंपनियां इस विचार के प्रति प्रतिरोधी हैं, परीक्षण करने के लिए आवश्यक समय के अल्पकालिक परिव्यय के कारण, यदि उत्पाद ठीक से नहीं करता है तो यह कितना समय बचाएगा वो क्या चाहते हैं)। हाँ, मैं Test Driven Development रास्ते जाने के लिए के रूप में दिख रहा है:
संपादित
तो, हाँ, मैं बात मैं कहना है कोशिश कर रहा हूँ लगता है। एक और बात जो मैंने निश्चित रूप से जिक्र नहीं की है वह तथ्य यह है कि परीक्षण कोड को दस्तावेज़ में मदद करते हैं। आपको पता चलेगा कि विधियों को क्या करना चाहिए, और आप सुनिश्चित होंगे कि जब भी आप किसी भी चरण में परिवर्तन करते हैं तो वे तब भी करते हैं।
मैं TDD वास्तव में उपयोगी पाया गया है, लेकिन कुछ डेवलपर्स लेखन कुछ नए कोड एक पुराने परीक्षण टूट जाता है जब तक यह का मूल्य नहीं दिख रहा।
मुझे यह करने में दिलचस्पी है, लेकिन यह सुनिश्चित नहीं है कि बड़ी परियोजनाओं के साथ इसे कैसे शुरू करना है, मैं भाग के माध्यम से शामिल होने के बाद ... एक परियोजना की वास्तविक ताजा शुरुआत में शामिल नहीं हूं 1996!
मुझे लगता है कि इसे पहले से बाहर परियोजनाओं पर आजमाने और पेश करना मुश्किल है। सबसे अच्छा आप आमतौर पर उम्मीद कर सकते हैं कि यूनिट परीक्षणों का एक सूट तैयार हो रहा है जो आपको आगे बढ़ने में मदद करता है, लेकिन आपको शायद कवरेज टेस्ट डिज़ाइन नहीं मिलेगा। – AshtonKJ
यूनिट परीक्षण मूल्य पर आता है। सबसे पहले, आपको उस अतिरिक्त कोड को लिखना और मान्य करना होगा। और फिर आपको यूनिट परीक्षण को गले लगाने के लिए प्रोजेक्ट टीम के भीतर एक महंगी संस्कृति परिवर्तन को धक्का देना पड़ सकता है।
यह कीमत आपके विशिष्ट प्रोजेक्ट के लिए भुगतान करने योग्य हो सकती है।निर्णय मतभेद या उपाख्यान पर आधारित नहीं होना चाहिए, बल्कि लागत और लाभों के सावधानीपूर्वक विश्लेषण पर होना चाहिए।
मैं आपसे असहमत हूं क्योंकि मुझे लगता है कि परीक्षण लंबी अवधि में लागत घटाने में मदद करते हैं क्योंकि यह बेहतर कोड लिखने में सहायता करता है। यह एक मतभेद मुद्दा नहीं है एक गुणवत्ता मुद्दा – roundcrisis
मुझे भी संदेह है कि इसका परिणाम कम लागत में होगा, लेकिन इसका मतलब यह नहीं है कि यह विश्लेषण के लायक नहीं है। –
कुछ ऐसे सिस्टम हैं जहां यूनिट परीक्षण को अपनाना उचित नहीं है। उन उदाहरण प्रणालियों के लिए जो मजबूत स्तरित दृष्टिकोण को अपनाते हैं और परिणामस्वरूप व्यापार और प्रस्तुति तर्क के मिश्रण में परिणाम नहीं लेते हैं। मेरा मानना है कि इस पर पहले से संबंधित स्टैक ओवरफ्लो प्रश्न है। –
सख्ती से टीडीडी नहीं, लेकिन मैं लिखने वाले कोड के प्रत्येक टुकड़े पर यूनिट परीक्षण करता हूं। मैं इसके बारे में सोचता हूं उसी तरह से मैं स्रोत नियंत्रण और रिफैक्टरिंग के बारे में सोचता हूं; गुणवत्ता कोड लिखने के लिए वे कुछ हैं जो आप करते हैं। मैं यूनिट परीक्षण के बारे में नहीं सोचूंगा।
मैं एक ही शिविर में हूं। मैं यूनिट टेस्ट (अक्सर टीडीडी लोगों के समान ढांचे का उपयोग करता हूं - मेरी पसंद एनयूनीट है), लेकिन अक्सर पूरे टीडीडी मंत्र के साथ "सब इन" नहीं जाते हैं। –
मेरी इच्छा है कि मैं अपनी परियोजना में यूनिट परीक्षण का अधिक उपयोग कर सकूं, और मेरी इच्छा है कि मेरे सहकर्मी कम से कम कुछ परीक्षण लिख रहे हों। :)
मेरे मामले में, वहाँ इकाई परीक्षण को सक्षम करने और TDD प्रथाओं का उपयोग कर के लिए एक काफी उच्च कीमत है। यह ज्यादातर औजारों पर निर्भर करता है, जो हमारे द्वारा उपयोग किए जा रहे ढांचे के लिए काफी खराब हैं। अगर पूरी परियोजना के लिए एक क्लिक द्वारा केवल यूनिट परीक्षण किया जा सकता था (या दो क्लिक, अगर हमें इस समय एक विशिष्ट परीक्षण की आवश्यकता होती है), तो यह बहुत आसान होता। जिन उपकरणों का हम अब उपयोग कर रहे हैं वे वास्तव में भुगतान नहीं करते हैं - परीक्षण चलाने के बजाए मैन्युअल रूप से बग को स्थानांतरित करना कभी-कभी आसान होता है।
जावा के साथ, बेहतर उपकरण हैं, इसलिए आपको वास्तव में परीक्षण लिखना शुरू करना चाहिए! डिबगिंग बेकार, वास्तव में चट्टानों का परीक्षण करता है।
आप किस ढांचे का उपयोग कर रहे हैं? आजकल इसकी अजीब मौजूदा ढांचे जो आसान यूनिट परीक्षण कार्यान्वयन की अनुमति नहीं देते हैं। – miguelbgouveia
दुर्भाग्य से हर बार नहीं। हमारा सबसे मिशन महत्वपूर्ण सिस्टम यूनिट परीक्षण से भरा है ताकि यह सुनिश्चित किया जा सके कि वे क्या कर सकते हैं, और डेवलपर्स की परवाह किए बिना इसे जारी रखें। अन्य प्रणालियों के लिए, ज्यादातर समय विकास के समय पर इसे खर्च करने के लिए विकास का समय बहुत छोटा होता है। (हालांकि अंत समय जीता में वहाँ डिबगिंग के बारे में दो बार खर्च है।)
हां। उन मामलों के अलावा जब किसी ग्राहक के पास बंदरगाह होता है तो मेरे सिर के आगे दिन के अंत तक दरवाजा से फीचर प्राप्त होता है।
यूनिट टेस्ट (मैं JUnit यहाँ सोच रहा हूँ) और TDD जाना है जब आप ताजा कोड के साथ एक नई परियोजना शुरू कर रहे हैं (और आप अधिक सीआई की तरह की आवश्यकता होगी) तरीका है।
लेकिन जब आपकी नई परियोजना उनमें से प्रत्येक में 5 केएलओसी के साथ तंग युग्मित वर्गों से भरे पुराने कोड बेस को संशोधित करना है तो इकाई परीक्षण कठिन है और अधिकांश समय परियोजना समय रेखा को एक रिफैक्टरिंग (या एक पुनर्लेखन)। यदि यह प्रोजेक्ट है जिस तरह से आप शुरू करने जा रहे हैं, तो मैं आपको पुरानी कोड पर रणनीतियों की जांच के लिए "विरासत संहिता के साथ काम करना" पढ़ने की सलाह देता हूं।
सभी नए विकास पर, अब हम टीडीडी करते हैं। विरासत रखरखाव के लिए, हम रिपोर्ट किए गए दोषों का पर्दाफाश करने और धीरे-धीरे एक पुस्तकालय बनाने के लिए असफल इकाई परीक्षण बनाते हैं।
यह एक संस्कृति सदमे में है, लेकिन यह वास्तव में भुगतान जब आपको लगता है कि आप नए विकास और कम समय बग-शिकार पर अधिक समय खर्च कर रहे हैं नहीं करता है।
हम क्लाइंट की तरह काम करने वाले कोड के एक वर्ग के बाद यूनिट परीक्षण करते हैं। सबसे पहले हम यूनिट टेस्टिंग को बहुत तेजी से कर रहे थे और जब ग्राहक अपना दिमाग बदलता है (और ऐसा होता है, तो मेरा विश्वास करो) आपको अक्सर कोड और यूनिट टेस्ट को हटाना होगा। यह बहुत समय लेने वाला और महंगा था।मैं यूनिट परीक्षण के लिए हूं, लेकिन TDD हमारे लिए कुछ आर्थिक नहीं था।
जब आप एक चर्चा मंच पर सवाल पूछते हैं, तो बहुत से लोग कहेंगे कि यूनिट परीक्षण "अनिवार्य" है, लेकिन वास्तविकता में यूनिट परीक्षण सर्वेक्षण के परिणामों के अनुसार दिखाए जाते हैं। अधिक संदर्भ/सामग्री के लिए http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2 देखें।
मैं एक परियोजना पर स्वचालित परीक्षण के बिना अब काम नहीं कर रहा कल्पना कर सकते हैं (यूनिट/एकता आदि ...)
वास्तव में, मैं अक्सर कहते हैं
"यदि यह टूट जाता है, इसकी मेरी गलती नहीं है"
लोगों के कोड पर काम करते समय परीक्षण नहीं होता है।
हाँ, जहां भी मैं कर सकता हूं। मुझे अपने द्वारा लिखे गए कोड का समर्थन करना है, और मुझे पता है कि विकास के दौरान बिताए गए अतिरिक्त समय की मामूली राशि मुझे रिहाई के बाद बिताए गए अतिरिक्त समय की एक असाधारण राशि से बचाती है।
यदि यह लिखने लायक था, तो यह परीक्षण के लायक है।
टीडीडी उड़ान भरने का एकमात्र तरीका है, ओह, मेरा मतलब कोड है। पेशेवर विकास में पिछले छह महीनों के लिए टीडीडी कर रहे थे। इससे पहले सिर्फ यूनिट परीक्षण था। सीखने में समय लगता है लेकिन मैं इसके बिना कभी नहीं जाऊंगा। –
मैं पूरी तरह से सहमत हूं। मैंने पारंपरिक झरना शैली डेवलपर के रूप में शुरू किया, लेकिन यूनिट परीक्षणों के बिना। अब मैं चुस्त, परीक्षण संचालित विकास की दिशा में आगे बढ़ रहा हूं। इससे क्या फर्क पड़ता है। प्रत्येक परीक्षण आपको पूरा होने के करीब महसूस करता है: डी – AshtonKJ