क्या इकाई परीक्षणों को चपल विकास के साथ प्रभावी ढंग से कार्यान्वित किया जा सकता है?

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

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

मुझे एहसास है कि अगर/जब आवश्यकताएं बदलती हैं (विशेष रूप से यदि स्प्रिंट के अंत की ओर) और तंग समय सीमा इकाई परीक्षण एक बोझ बन जाएगा। इस मामले पर किसी के पास कोई अच्छी सलाह है?

स्रोत

2010-07-29 Scozzard

यह प्रश्न ऑफ-विषय है क्योंकि यह इस साइट के दायरे में नहीं है, जैसा कि [मैं यहां कौन से विषय पूछ सकता हूं?] (// stackoverflow.com/help/on-topic) यह भी देखें: [क्या प्रश्नों के प्रकारों से मुझे पूछने से बचना चाहिए?] (// stackoverflow.com/help/dont-ask) आप [अन्य स्टैक एक्सचेंज साइट] (// stackexchange.com/sites#name) पर पूछने में सक्षम हो सकते हैं, * शायद * [pm.se] या [softwareengineering.se]। किसी भी साइट पर एक प्रश्न पोस्ट करने का इरादा रखने के लिए सहायता केंद्र के विषय-वस्तु पृष्ठ को पढ़ना सुनिश्चित करें। – Makyen

@Makyen यह प्रश्न 7 साल पहले पोस्ट किया गया था जब ये अन्य एक्सचेंज मौजूद नहीं थे/इनके बारे में अच्छी तरह से ज्ञात नहीं थे या सीमाओं को स्पष्ट रूप से परिभाषित नहीं किया गया था ... तो, ओह .. जानकारी के लिए धन्यवाद? क्या एक अजीब अद्यतन है। – Scozzard

@ माक्यन क्या आप सचमुच पुराने पदों में से सबसे पुराने हैं और अक्सर पूछे जाने वाले प्रश्नों के आधार पर सलाह दे रहे हैं? आपके दोस्त से पहले आपके पास लंबी सड़क है! – Scozzard

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

स्रोत

2010-07-29 23:09:24 Mathias

आपकी दूसरी बात मेरी पुस्तकों में सबसे महत्वपूर्ण है। ज्ञान में चीजों को सुरक्षित रखने में सक्षम होने के कारण शेष प्रणाली अभी भी काम करती है, जिससे वे बदलाव करना अधिक आसान हो जाता है। –

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

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

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

स्रोत

2010-07-29 23:27:30

मैं उन परियोजनाओं में काम करता हूं जो वर्षों लेते हैं और कोई परीक्षण कवरेज नहीं है। ऐसा नहीं है कि मुझे यह पसंद है। हर्गिज नहीं। –

@Peri - मुझे आपके लिए खेद है, और दुख की बात है, कई परियोजनाएं इस तरह हैं। उम्मीद है कि बहुत से ग्रीनफील्ड परियोजनाएं स्वचालित परीक्षण पर स्किमिंग शुरू नहीं करती हैं। हालांकि बहुत देर हो चुकी है, मुझे 0% कवरेज के साथ सिस्टम सौंप दिए गए हैं और 50% तक इसे कम करने में सक्षम हैं, धीरे-धीरे टुकड़ों का परीक्षण करते हैं क्योंकि वे नए बदलावों से गुजर चुके हैं। –

जब तक आपके पास उच्च कवरेज के साथ यूनिट परीक्षण न हो, तब तक परिवर्तन की लागत तेजी से बढ़ेगी क्योंकि परियोजनाएं आगे बढ़ती हैं। तो मूल रूप से, जितना अधिक परिवर्तन आप अनुमान लगाते हैं, आपको वास्तव में अपने यूनिट परीक्षणों की आवश्यकता होगी।

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

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

स्रोत

2010-08-11 15:26:03 Mahol25

क्या इकाई परीक्षणों को चपल विकास के साथ प्रभावी ढंग से कार्यान्वित किया जा सकता है?

उत्तर

संबंधित मुद्दे