परीक्षण-संचालित विकास कौन करता है?

Question

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

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

किस प्रकार की दुकानों, कंपनियों और ग्राहकों के साथ परीक्षण-संचालित विकास कार्य सर्वोत्तम है? टीडीडी के लिए किस प्रकार की परियोजनाएँ अनुकूल होती हैं?

Comments

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

— bzlm

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

— बिल

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

— रीन हेनरिच्स

@ रीन: अमन, भाई !!

— आइब्रीस्ट

क्या यह प्रश्न सूची शैली के उत्तर को वास्तविक मानदंडों के साथ प्रोत्साहित नहीं करता है जब इसे "सही ढंग से" उत्तर दिया गया है? StackExchange के Q & A प्रारूप के लिए इस प्रकार के प्रश्नों को अयोग्य नहीं माना जाता है क्योंकि हम 16+ उत्तरों के साथ समाप्त होते हैं, जिनमें से प्रत्येक प्रश्न को संबोधित करता है, जिनमें से कोई भी "सही" के लिए गैर-मौजूद एक्जिट मानदंड को पूरा नहीं करता है?

— नाथन सी। ट्राईसच

Answer 1

कोड की प्रत्येक पंक्ति मैं परीक्षण संचालित विकास का उपयोग कर रहा हूं। यदि प्रबंधन पहले परीक्षण लिखने के साथ बोर्ड पर नहीं है, तो मैं प्रबंधन को इसके बारे में नहीं बताता। मुझे लगता है कि दृढ़ता से परीक्षण संचालित विकास एक बेहतर प्रक्रिया है।

Comments

मैंने आपको विशेष रूप से अपवित्र नहीं किया क्योंकि आप TDD करते हैं, लेकिन क्योंकि आप जो सोचते हैं वही करते हैं, बिना अनुमति लिए। यही प्रोफेशनल्स करते हैं।

— सर्जियो अकोस्टा

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

— luis.espinal

एक पेशेवर क्या है की परिभाषा के रूप में मैंने क्या नहीं कहा। और एक जटिल विषय के गहन उपचार में दो वाक्य की टिप्पणी की अपेक्षा न करें। माफ़ कीजिये।

— सर्जियो अकोस्टा

इसके बारे में कैसे: "एक पेशेवर सही काम करता है बिना उसे बताया जाए"। बेहतर? यही मेरा मतलब था।

— सर्जियो एकोस्टा

@ क्रेगटप - पीपुलवेयर: प्रोडक्टिव प्रोजेक्ट्स एंड टीम्स नामक पुस्तक में एक पूरा अध्याय है, जो "कार्यप्रणाली" के खिलाफ कहती है कि यह प्रेरणा को मारती है और भीतर की ज्वाला को बुझा देती है यदि "कार्यप्रणाली बहुत तंग है क्योंकि यह दूर हो जाती है" व्यक्तिगत रूप से यह मानने की स्वतंत्रता कि वे व्यवस्थित रूप से बुरा विकल्प बनाएंगे। एक अच्छा काम करने का माहौल वह है जहां व्यक्ति निर्णय ले सकता है कि वह "अधिक अच्छे" के लिए सबसे अच्छा है, अगर यह विफल हो जाता है तो समायोजित करें, लेकिन अन्यथा, व्यक्ति को निर्णय का केंद्र होने दें, न कि "कार्यप्रणाली"

— JF डायोन

Answer 2

मेरे मालिक ने आज मुझे इस पर एक अच्छा खिलाया, मुझे लगता है कि मैं इसे चोरी करने जा रहा हूं जैसे वह किसी और से चोरी कर रहा था।

"क्या आप एक बढ़ई से बोर्ड को मापने से पहले उम्मीद करेंगे कि वह इसे काटे?"

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

Comments

मैं यह नहीं कह सकता कि मैं उस सादृश्य से सहमत हूं। यह वास्तव में विकास की जटिलताओं के करीब नहीं आता है। लेकिन फिर, मैं पूरी तरह से TDD में विश्वास नहीं करता।

— xil3

@ xil3 हां, उपमा अच्छी नहीं है। यह अधिक होगा "लगभग मापने, बाद में जांच नहीं, और फिर काटने"। लेकिन जवाब अभी भी बहुत अच्छा है

— Bћови

Answer 3

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

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

आप एक झरना परियोजना में भी ड्राइव कोड का परीक्षण कर सकते हैं, यह एक इंजीनियरिंग अनुशासन है जो परियोजना प्रबंधन तकनीक नहीं है।

मैं किसी भी तरह से एक TDD कट्टरपंथी नहीं हूँ, लेकिन यह आपको सॉफ्टवेयर डिज़ाइन के बारे में बहुत कुछ सिखाता है।

Comments

"यदि आप परीक्षण करते हैं, तो आप फिर से काम करते हैं क्योंकि आपके द्वारा लिखा गया कोड परीक्षण करना मुश्किल होगा।" यह वास्तव में सच नहीं है। यदि आप ढीले कपल कोड नहीं बनाते हैं तो यह केवल सच होगा। आप कर रहे हैं यकीन है कि आप नहीं कर सकते हैं यह पहली बार परीक्षण के बिना परीक्षण योग्य कोड लिखने?

— 21:00 बजे ईलिसियम भस्म हो गया

@ देहाती एलीसियम: मैं सहमत हूं: पहले परीक्षण लिखना परीक्षण योग्य कोड लिखने का एकमात्र तरीका नहीं है।

— जियोर्जियो

Answer 4

मेरे साथ सहन करें, क्योंकि इसमें एक अलग .Net स्वाद होगा: पी

उन परियोजनाओं के प्रकारों के संबंध में जो परीक्षण-प्रथम दृष्टिकोण के लिए उत्तरदायी हैं, कुछ चीजें जिन्हें मैं देखूंगा:

• क्या आप मौजूदा कोड आधार के साथ काम कर रहे हैं? यह अक्सर निषेधात्मक रूप से महंगा होता है कि इसमें एक परीक्षण सूट हो। एक अनुमान प्राप्त करें कि कितना विरासत में मिला तकनीकी ऋण है
• कुछ प्लेटफ़ॉर्म और चौखटे स्वाभाविक रूप से परीक्षण-अमित्र हैं। हाल का अनुभव जो मेरे दिमाग में है - SharePoint, उदाहरण के लिए TDD के लिए बहुत कठिन (लेकिन असंभव नहीं है)। इस तरह के सामान के लिए, आपको एक वाणिज्यिक आइसोलेटर उत्पाद का सहारा लेना पड़ सकता है, जैसे टाइपमॉक मदद कर सकता है।
• कुछ कार्यान्वयन दृष्टिकोण दूसरों की तुलना में खुद को टीडीडी के लिए बेहतर मानते हैं। उदाहरण के लिए, कोड के साथ ASP.Net- behinds - इतना परीक्षण करने योग्य नहीं है। ASP.Net MVC - परीक्षण योग्य। कोड- behinds के साथ सिल्वरलाइट - ऐसा परीक्षण करने योग्य नहीं है। MVVM के साथ सिल्वरलाइट - परीक्षण योग्य।

अंततः, जबकि "संगठन" परीक्षण-प्रथम की चाल का समर्थन करने के लिए बहुत कुछ कर सकता है, जो प्रमुख बदलाव होना चाहिए, जो डेवलपर्स के दिमाग में है। मैंने "तू पहले लिखो परीक्षण पहले" लिख दिया है और इसके बजाय यह देखने योग्य क्षणों के लिए देखना है।

एमएफएनआरओ की टिप्पणी पर +1 एमजीएमटी को नहीं बताने के बारे में कि क्या उनके पास कोई मुद्दा है: पी

Comments

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

— वेन मोलिना

Answer 5

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

आप अच्छे व्यवसाय के मामले भी बना सकते हैं:

• टीडीडी को केवल "युक्ति के रूप में सारांशित किया जा सकता है जिसे सिस्टम स्वतः ही अपने खिलाफ सत्यापित कर सकता है"। यह अलग तरह से प्रोग्रामिंग नहीं कर रहा है, यह एक अलग उत्पाद नहीं बना रहा है।

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

• TDD, जब किसी के द्वारा किया जा रहा है जो जानता है कि वे क्या कर रहे हैं, तो कोड-प्रथम के रूप में तेजी से परिणाम उत्पन्न करता है। एक सीखने / प्रशिक्षण वक्र होगा (और, यदि आपके इंजीनियर प्रतिभा पूल के लघु-अंत से हैं तो यह पूरी तरह से TDD को आगे बढ़ाने के आपके अवसरों को मार सकता है - इस मामले में सबसे अच्छा आप यह कर सकते हैं कि इसे जारी रखना है। और प्रबंधन से सवाल करें बजाय उन्हें TDD के)

• टीडीडी इसे शुरू करने से पहले हाथ में कार्य के माध्यम से सोचने के बारे में बहुत अधिक है। यह "माप दो बार, एक बार कटौती" की पंक्तियों के साथ है - अतिरिक्त मापक कार्य में समय की एक मामूली राशि जोड़ता है, लेकिन अपने सबसे कीमती संसाधन - देव घंटों को फेंकने से बचा जाता है)।

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

Answer 6

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

Answer 7

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

यदि आप समझाते हैं कि "मैं परीक्षण लिख रहा हूँ," तो द पावर्स दैट बी कह सकता है "ओह, हम इसे समाप्त कर सकते हैं!" लेकिन अगर आप किसी को नहीं बताते हैं, तो आपके पास अभी भी कोडिंग प्रक्रिया के अवशेष के रूप में परीक्षण हैं।

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

Comments

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

— जियोर्जियो

Answer 8

कहने के लिए दुःख की बात है कि मुझे वास्तव में क्लासिक टेस्ट-फस्र्ट सेंस में खुद को इस्तेमाल करने का मौका नहीं मिला है, इसलिए मैं इसे मुझे नहीं कह सकता! मैं! मैं यह करता हूं! "। मैं यह मान रहा हूं कि यह सवाल "बोर्ड / टीडीडी का उपयोग करने वाले उद्योग" क्या कर रहे हैं "इसके बजाय" क्या कोई अपने दैनिक जीवन में टीडीडी को छीन सकता है? "। मैं मानता हूं कि एक व्यक्तिगत डेवलपर पूरी तरह से पूरे समूह को मजबूर किए बिना टीडीडी कर सकता है, मुझे नहीं लगता कि यह प्रश्न का बिंदु था।

उद्योग के चारों ओर सुनने से मेरी धारणा यह है कि आप ऐसी स्थितियों में जहां एक कंपनी में अधिकांश विकास समूहों में TDD देख सकते हैं:

• TDD की स्थापना से पहले कोई बड़ा मौजूदा कोड आधार नहीं है

• कंपनी बहुत बड़ी नहीं है और इसलिए हमारे पास "हमने इसे हमेशा दूसरे तरीके से किया है" पुशबैक नहीं किया है।

• कंपनी के पास औपचारिक प्रक्रिया में एक बड़ी खरीद नहीं है। यह कहने के लिए नहीं है कि आप TDD को लागू नहीं कर सकते, उदाहरण के लिए, एक CMMI प्रमाणित कंपनी - लेकिन अगर आपके पास एक नहीं-TDD प्रक्रिया थी, तो उन सभी प्रक्रियाओं को प्राप्त करना जिन्हें आप CMMI के साथ अद्यतन करते हैं, एक प्रमुख निवेश हो सकता है।

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

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

• हितधारकों जो इस प्रक्रिया में निवेश किए जाते हैं।

Comments

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

— वेन मोलिना

Answer 9

मैंने जहाँ संभव हो कोशिश की है - लेकिन मुझे लगता है कि यह वास्तव में कॉर्पोरेट वातावरण के लिए नीचे है जिसमें आप खुद को पाते हैं। मैंने कई वर्षों तक खेल उद्योग में काम किया (बतौर कलाकार btw), और TDD की कोई अवधारणा नहीं थी - सिर्फ एक क्रूर बल QA दृष्टिकोण। मैं वेब विकास में चला गया, और अभी तक किसी भी एजेंसी में काम करने के लिए किसी भी औपचारिक मान्यता (या ... का ज्ञान) के साथ इकाई परीक्षण / टीडीडी है। उद्योग में मेरे अधिकांश साथियों के लिए भी यही बात है, जो व्यापक विषयों में काम करते हैं।

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

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

Answer 10

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

इसलिए मुझे लगता है कि आपको किसी प्रकार का LearningTests करना है, प्रूफ-ऑफ-कांसेप्ट्स को फिर से लिखना है और इसे आगे लिखना है, या क्या मैं गलत हूं?

और (मुझे पता है कि यह एक पुराना है, लेकिन मुझे अभी तक कोई अच्छा जवाब नहीं मिला है): आप टीडीडी का उपयोग करके कोड एल्गोरिदम कैसे बनाते हैं (जब परिणाम वास्तव में "Assert" पर आसानी से जटिल हो सकते हैं)?

मैं वास्तव में TDD के सकारात्मक पक्षों को देख सकता हूं और नाव पर im कर सकता हूं, लेकिन शुरुआती लोगों के लिए यह बहुत कठिन है जब आप जो कोड लिखते हैं वह आपको समय से दोगुना ले जाता है (और आपको सहकर्मी मिल गए हैं जो पेशेवरों को बिल्कुल नहीं देखते हैं और आपका मजाक उड़ाते हैं। राड के साथ)

Answer 11

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

Comments

लाभ बाद में आता है, क्योंकि आप मूल रूप से कोड के रूप में व्यवहार का दस्तावेजीकरण कर रहे हैं। कोई भी कोड परिवर्तन अभी भी परीक्षण पास करना होगा या व्यवहार बदल गया है।

Answer 12

मैं करता हूं। हमारी उपयोगकर्ता कहानियों की प्रगति एक कानबन बोर्ड पर नज़र रखी जाती है, जिसमें "टेस्ट है?" विकास के बाईं ओर (ऊपर की ओर) स्तंभ।

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

स्वीकृति-परीक्षण फीडबैक लूप एक प्रकार का लंबा है: कहानी को पूरा करने में कई दिन लग सकते हैं। विकास का अपना, छोटा TDD फीडबैक है।

"[... नो टेस्ट-फर्स्ट स्टाइल ...] एगलेस टू एजाइल ...।"

यह एजाइल की पूरी गलत व्याख्या है। किया की परिभाषा एजाइल का एक प्रमुख घटक है और इसमें से एक खंभा जिस पर टिकी हुई है वह है स्वचालित स्वीकृति परीक्षण (जो मैंने ऊपर वर्णित किया है वह इसे करने का एक तरीका है।) यदि चरम प्रोग्रामिंग (एक्सपी) का उपयोग एक चुस्त कार्यान्वयन विधि के रूप में किया जाता है, तो। ATDD / BDD और TDD निर्धारित हैं।

Answer 13

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

अनिवार्य रूप से, मैं तब करता हूं जब आवश्यकता की जटिलता का मतलब है कि मैं कोड में खो सकता हूं।

इसे शुरू करना एक कठिन आदत है, और इसके लिए प्रबंधन को खरीद की आवश्यकता होती है, लेकिन, जब आपके परीक्षण विकास के माध्यम से आधे रास्ते को तोड़ने लगते हैं, तो यह एक जीवन रक्षक हो सकता है!

Answer 14

मैं यह बहुत ही सवाल पूछना चाहता था, यह देखने के लिए कि वास्तव में कितनी कंपनियां टीडीडी का अभ्यास कर रही थीं।

11 वर्षों में, मैं पेशेवर रूप से केवल पिछले दो संगठनों को TDD के बारे में जानता था (जो कि लगभग 5 साल के दिमाग तक फैला था, उस समय से पहले TDD उतना लोकप्रिय नहीं था जितना आज है)। मैं टीडीएस के लिए मेरी बिक्री पिच में खुदाई करने से पहले आपका पीछा करने और आपके सवाल का जवाब दूंगा :)

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

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

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

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

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

बिक्री पिच ...

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

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

गैर-प्रोग्रामर के पास (अक्सर) यह अंतर्दृष्टि नहीं होती है और इसलिए टीडीडी उनके लिए बहुत अधिक मूल्य नहीं रखता है, और इसे पहले रिलीज की तारीख के लिए डिस्पोजेबल शॉर्टकट के रूप में देखा जाता है।

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

में मेरी राय सॉफ्टवेयर विकास उद्योग (पूरे पर), वर्तमान में टूट गया है तथ्य यह है कि आपके सॉफ़्टवेयर के लिए परीक्षण कर रहा आदर्श नहीं है।

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

शायद यह कहना अनुचित है कि कोई परीक्षण नहीं होता है क्योंकि यह होता है ... लेकिन स्वचालित परीक्षण के बिना कंपनियों में, यह बहुत मैनुअल / मानव है (क्लंकी पढ़ें और अक्सर त्रुटि प्रवण) प्रक्रिया।

एक बिंदु मैं आपके प्रश्न पर विचार करूंगा ...

वे आमतौर पर चाहते थे कि विकास तुरंत शुरू हो, या एक छोटे डिजाइन के बाद। एजाइल को और अधिक।

होने के नाते "फुर्तीली" परीक्षण के बिना नहीं आगे बढ़ने की सलाह है, पर सूचीबद्ध पहले सदस्य agilemanifesto.org है केंट बैक , XP और TDD के निर्माता!

अगर आप TDD में रुचि रखते हैं, या सिर्फ उन्हें नहीं पढ़ा है और एक उत्सुक प्रोग्रामर हैं (तो यह सही पढ़ रहे हैं?);

टेस्ट द्वारा बढ़ते ऑब्जेक्टेड ओरिएंटेड सॉफ्टवेयर गाइडेड

क्लीन कोड - रॉबर्ट सी मार्टिन ("अंकल बॉब") श्रृंखला

ये दोनों पुस्तकें एक-दूसरे की प्रशंसा करती हैं और कुछ पन्नों में बहुत कुछ बयां कर देती हैं।

यह सवाल पूछने के लिए धन्यवाद :)

Answer 15

जो क्लोन लागू करते हैं। जब आप किसी चीज़ को विकसित करने के लिए बेहतर प्रक्रिया के बारे में नहीं सोच सकते, तो वह मौजूदा प्रोग्राम की तरह ही काम करता है।

Comments

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

— फ्रैंक शीयर

Answer 16

जाहिर है यह एक बहुत ही असामान्य मामला है, लेकिन SQLite के डेवलपर्स बड़े पैमाने पर परीक्षणों का उपयोग करते हैं। (मुझे लगता है कि उनकी विकास प्रक्रिया परीक्षण-प्रथम है, हालांकि मुझे यकीन नहीं है।)

• कोड की 73,000 लाइनें
• परीक्षण कोड की 91,378,600 लाइनें

Http://www.sqlite.org/testing.html देखें