इकाई परीक्षणों के बिना फुर्तीली

27

क्या यह "फुर्तीली विकास" के बारे में बात करने या यह दावा करने के लिए कि आप एक "चुस्त कार्यप्रणाली" को लागू कर रहे हैं यदि आप जिस कोड आधार पर काम कर रहे हैं, उसमें 0% यूनिट टेस्ट कवरेज है? (और आप, एक टीम के रूप में, इसके बारे में कुछ भी नहीं कर रहे हैं)।

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

हो सकता है कि कुछ अन्य तरीके भी हों, लेकिन मैं अभी भी नहीं देख सकता कि वे कैसे काम कर सकते हैं।

unit-testing agile tdd

— ईविल टॉड
स्रोत

14

एजाइल के पास इसे वापस करने के लिए स्वचालित परीक्षण के साथ सफल होने की अधिक संभावना है। मुझे पहले परीक्षणों के बिना एजाइल लागू करने के लिए मजबूर किया गया है और यह एक जाल है। यह पहले की तुलना में तेजी से तकनीकी ऋण जमा करने का एक सुविधाजनक तरीका है।

— मेटाफाइट

5

टीडीडी आवश्यक रूप से एकमात्र अभ्यास नहीं है जो आपको वहां ले जाता है। यह एक आम है, हालांकि। व्यक्तिगत रूप से, मैं BDD को अधिक व्यावहारिक दृष्टिकोण मानता हूं।

— मेटाफ़ाइट

6

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

— जियोर्जियो

वैसे यह प्रश्न मिश्रित इकाई परीक्षण और टीडीडी है जिससे आप टीडीडी के बिना इकाई परीक्षण कर सकते हैं।

— वालफ्रैट

यहाँ के जवाबों को पढ़कर मुझे आश्चर्य होता है कि जब मैंने 00 के दशक के मध्य में चंचलता सीखी थी तब से कितनी चीजें बदल गई हैं। TDD और जोड़ी प्रोग्रामिंग को उच्च गति पर उच्च गुणवत्ता कोड बनाए रखने के लिए ESSENTIAL चुस्त अभ्यास माना जाता था।

— नौ

37

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

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

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

— रबर की बतख
स्रोत

क्या आपको फुर्तीले होने के लिए एजाइल मेनिफेस्टो का पालन करना होगा?

— जेफ़ओ

कोई @ जेफ। आप नहीं, लेकिन यह निश्चित रूप से मदद करता है। मैंने अपना इरादा स्पष्ट करने के लिए संपादन किया।

— रबरडक

1

IMO सबसे फुर्तीले प्रोग्रामर वे हैं जो बहुत व्यावहारिक हैं, भले ही उन्होंने चुस्त घोषणापत्र के बारे में कभी नहीं सुना हो।

— जियोर्जियो

1

मैं आपसे वहां @ असहमत नहीं हो सकता। मैं पहले भी चुस्त टीम में था, हम में से किसी ने कभी भी एजाइल के बारे में सुना।

— रबरडक

2

@CortAmmon - यदि आप एजाइल (अपनी कार्यप्रणाली में बड़े "ए" चुस्त) को परिभाषित करना चाहते हैं, तो मैं आपसे सहमत होगा, लेकिन अगर आप चुस्त (छोटे "" ए "होना चाहते हैं, जैसा कि वास्तव में चुस्त होना है तो आप बदलावों को बेहतर तरीके से संभाल सकते हैं। ), तो आपको किसी विशेष कार्यप्रणाली का पालन करने की आवश्यकता नहीं है। यदि आप झरना कर सकते हैं और फिर भी परिवर्तन संभाल सकते हैं (मुश्किल, लेकिन असंभव नहीं), कौन परवाह करता है?

— जेएफओ

30

फुर्तीली घोषणा पत्र में कहा गया है:

व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत

व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर

अनुबंध बातचीत पर ग्राहक सहयोग

एक योजना के बाद बदलने का जवाब

वहां यूनिट परीक्षणों का कोई उल्लेख नहीं है। यहां तक कि 12 सिद्धांतों में परीक्षण का उल्लेख नहीं है।

इसलिए, तकनीकी रूप से, यूनिट परीक्षणों को लिखे बिना एक फुर्तीली टीम होना संभव है। व्यवहार में, यह देखना वास्तव में कठिन है कि एक टीम निरंतर बदलाव करने में उनकी सहायता करने के लिए परीक्षण के बिना एक चुस्त वातावरण में काम करने वाले सॉफ़्टवेयर को कैसे बनाए रख सकती है।

— डेविड अरनो
स्रोत

4

यह देखना कठिन है कि कोई टीम बिना किसी परीक्षण के किसी भी वातावरण में काम करने वाले सॉफ्टवेयर को कैसे बनाए रख सकती है ।

— ब्रायन ओकले

6

सिर्फ इसलिए कि कुछ देखने के लिए कठिन है यह असंभव नहीं है

— Ampt

8

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

व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर ।

अगर सॉफ्टवेयर काम कर रहा है तो किसी को कैसे पता चलेगा? घोषणापत्र को स्पष्ट रूप से शब्द परीक्षण की आवश्यकता नहीं है। यह सक्सेसफुल है।

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

— एक्सल
स्रोत

3

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

— टी। सार - पुनर्वसु मोनिका

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

— एक्सल

मैं आपकी बात समझता हूं। हालांकि, सवाल विशेष में यूनिट परीक्षणों के बारे में पूछता है , सामान्य रूप से बिल्कुल परीक्षण नहीं। प्रश्न के संदर्भ पर आपके उत्तर को पढ़ने से आपके परीक्षण को "इकाई परीक्षण" माना जाता है!

— टी। सर - पुनर्विचार मोनिका

वहाँ, इसके लिए क्षमा करें।

— एक्सल

2

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

— सोलोमन स्लो

2

यह बिल्कुल समझ में आता है। चंचलता परीक्षण के बारे में नहीं है, जैसा कि दूसरों ने पहले ही उल्लेख किया है, लेकिन विशेष रूप से आपके प्रश्न का उत्तर देने के लिए:

नहीं, आपको इकाई परीक्षण की आवश्यकता नहीं है।

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

आपको मिल सकता है इकाई परीक्षण आपको विकसित करने में मदद करता है, और उसके लिए पर्याप्त रूप से उचित है, लेकिन कई चीजें हैं जो विकास में मदद कर सकती हैं जो आपके पास नहीं हो सकती हैं।

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

— gbjbaanb
स्रोत

आप केवल एकीकरण परीक्षण के साथ एक चुस्त प्रक्रिया चला सकते हैं। क्या यह सैद्धांतिक है या अनुभव से बोला गया है?

— आर साहू

1

इसकी आवश्यकता नहीं है। परीक्षण बहुत अच्छा है जब आपके पास ऐसे लोग हैं जो वास्तव में जानते हैं कि इसका उपयोग कैसे करना है। जब आप नहीं करते हैं, न केवल यह आवश्यक नहीं है, यह एक दायित्व बन जाता है। मैं कहूंगा कि कई प्रोग्रामर हैं जो इस पर बहुत कुशल नहीं हैं।

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

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

— JeffO
स्रोत

1

मैं तर्क (अन्य उत्तरों) का जवाब देना चाहूंगा कि एजाइल घोषणा पत्र स्पष्ट रूप से इस बारे में कुछ बताता है, अर्थात्:

तकनीकी उत्कृष्टता और अच्छे डिजाइन के लिए निरंतर ध्यान चपलता को बढ़ाता है।

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

संगठनात्मक चपलता तकनीकी चपलता से विवश है

दूसरे शब्दों में, जब आप अपने उत्पाद में बदलाव करने में धीमे होते हैं, तो इससे कोई फर्क नहीं पड़ता कि आप अपनी टीमों, अपने संगठन या आप किस ढांचे को अपनाते हैं, आप परिवर्तनों का जवाब देने में धीमे होंगे।

यदि आप अपने उत्पाद को दूसरे तरीके से परिवर्तन का विरोध करने से रोक सकते हैं तो आप सही रास्ते पर हो सकते हैं, लेकिन:

मैंने प्रोग्रामर्स के लिए दुनिया को सुरक्षित बनाने के लिए एक्सट्रीम प्रोग्रामिंग का आविष्कार किया। - कैंट बेक

स्क्रैम में किसी भी तकनीकी अभ्यास का अभाव है, लेकिन जेफ ने इसके बारे में निम्नलिखित बातें कही:

मैंने कभी भी एक अति-उत्पादक स्क्रैम टीम को नहीं देखा है जो चरम प्रोग्रामिंग विकास प्रथाओं का उपयोग नहीं करता है। - जेफ सदरलैंड

इस लेख से उद्धृत: http://ronjeffries.com/articles/017-02ff/gathering2017/

मैं उम्मीद करूंगा कि आखिरकार तकनीकी अभ्यासों के बिना स्क्रम टीमों को एक समान अभ्यास के साथ रेट्रोस्पेक्टिव का उपयोग करके आना चाहिए। आप हाइपर-प्रोडक्टिव भी बनना चाहते हैं, नहीं?

चंचल प्रभाव मॉडल, दो स्टार स्तर में यह उल्लेख है:

उपयोगी तकनीकों में निरंतर एकीकरण, परीक्षण-संचालित विकास , जोड़ी प्रोग्रामिंग और सामूहिक स्वामित्व शामिल हैं।

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

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

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

— नील्स वैन रिइजर्सडाल
स्रोत

1

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

— वालफ्रैट

2

तकनीकी रूप से सहमत नहीं है, लेकिन उच्च स्तर पर परीक्षण अक्सर अधिक भंगुर होते हैं, बनाए रखने के लिए कठिन होते हैं और शायद आपको अंत में धीमा कर देते हैं यदि आपके पास उनमें से बहुत से हैं। मुझे पसंद है कि मार्टिन फाउलर इसे कैसे कहते हैं: "यदि आपको उच्च स्तर के परीक्षण में असफलता मिलती है, तो न केवल आपके कार्यात्मक कोड में एक बग है, आपके पास एक लापता या गलत इकाई परीक्षण भी है।" से martinfowler.com/bliki/TestPyramid.html

— नील्स वैन Reijmersdal

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

— वॉलफ्रैट