परीक्षण-संचालित विकास - गाड़ी या घोड़ा?

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

टेस्ट प्रेरित विकास - फैशन का पालन करने का प्रयास? अन्य लोगों के दृष्टिकोण की नकल अंधा?

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

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




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



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

TDD - डेवलपर की पहल को प्राप्त करता है। पहले से ही डेवलपर स्वयं इस प्रक्रिया को नियंत्रित नहीं करता है, लेकिन कार्य "स्नोबॉल के साथ गिरता है"? क्या कोई मनोवैज्ञानिक असुविधा है? हमारे प्रोग्रामर अब एक निर्माता नहीं है, लेकिन कार्यक्षमता को लागू करने के लिए एक नासमझ मशीन है?

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



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

टीडीडी - कार्यान्वयन की गुणवत्ता पर नहीं, बल्कि क्षणिक सुविधाओं पर केंद्रित है। हम कोड की गुणवत्ता के बारे में कैसे बात कर सकते हैं? सिस्टम आर्किटेक्चर के बारे में क्या? कार्यक्रम कोड के दृष्टिकोण से, क्या हमें "ओलिवियर सलाद" मिलता है - विभिन्न स्वादों और रंगों के बारीक कटे हुए टुकड़ों का एक यांत्रिक मिश्रण? क्या आप मानते हैं कि बड़े ढेर में बंद एक विनिगेट, एक वास्तुशिल्प परिपूर्ण और रचनात्मक गुणवत्ता का प्रतीक हो सकता है?

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



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

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



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

इसलिए ... "प्रबंधन" (निदेशालय और विशेष रूप से ग्राहक) वास्तव में परवाह नहीं करते हैं कि क्या तकनीकों का उपयोग किया जाता है (दुर्लभ अपवादों के साथ, जिसकी हम उम्मीद नहीं करेंगे)। सामान्य तौर पर, कोई भी मंडराता नहीं है, और डेवलपर्स "अंदर" क्या करते हैं। वे RUP, TDD / ShmeDD, Agile / SuperAgile या कुछ और का उपयोग करते हैं ...



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

ऊपर से कोई टेस्ट नहीं दिए गए हैं। टेस्ट डेवलपर्स का एक आंतरिक मामला है। और बेहतर परीक्षण और अधिक वे कर रहे हैं, और अधिक "बेहतर नींद" डेवलपर्स। और कम उन्हें कालीन पर बुलाया जाता है। टेस्ट डेवलपर्स के लिए हैं, बॉस के लिए नहीं।

TDD अक्षम लोगों और कोडिंग से दूर अपनी स्वयं की विचारधारा विदेशी को बढ़ावा देने के लिए डेवलपर्स के लिए एक प्रयास है ... अपने स्वयं के, अक्सर उत्पाद विकास रणनीति की गलत दृष्टि।

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

मान लीजिए कि मुझे टीडीडी तकनीक का पालन करने के लिए बाध्य किया गया था, हालांकि, आपको मानना ​​होगा कि बहुत सारे लोग इसके बिना सहज महसूस करते हैं। खैर, यह सामान्य तकनीक की तुलना में क्या देता है, जब "उन्होंने योजना बनाई - कार्यान्वित की गई - परीक्षण किया - परीक्षण किया"? बॉस के लिए बस एक "सुंदर परी कथा" "क्या हम उन्नत दृष्टिकोण का उपयोग करते हैं?"

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



एक बार फिर: "किस्से" - नहीं, मालिकों - सभी एक ही, उसे एक परिणाम, शर्तों और गुणवत्ता की आवश्यकता है।

मैंने परीक्षाओं को गड़बड़ कर दिया। मैंने उनके लिए (अनिच्छा से) कार्यात्मक कोड को अनुकूलित करना शुरू कर दिया। यह पता चला है ... फिर, कि परीक्षण गलत तरीके से आविष्कार किया गया था। क्या मैं बर्बाद हो गया हूं?

यह "बकवास अप" आवश्यक नहीं है। एक विशेषता - एक परीक्षण। Iteratively। एक विशेषता एक परीक्षण को जन्म देती है, और एक परीक्षण एक विशेषता को जन्म देती है। एक्सपी, चुंबन-सिद्धांत।

लेकिन क्या ऐसा नहीं होता है कि "परीक्षण", जिसने "कठिन असाइनमेंट" का रूप ले लिया है, एक दूसरे के साथ विरोधाभास करने लगते हैं?

यह "शानदार" की श्रेणी से मेरा पसंदीदा प्रश्न है! यदि परीक्षण एक-दूसरे का खंडन करते हैं, तो:
- टीके अच्छी तरह से विकसित नहीं है;
- टीके विरोधाभासी है।
यहां परीक्षणों के लिए "धन्यवाद" कहना और TK के विकास पर वापस जाना आवश्यक है।

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

तार्किक है। तो कई करते हैं। एक कोड लिखते हैं। आइए लिखने। सीवीएस / एसवीएन में इसे कमिट करें। तो क्या? क्या हमने अपना काम किया है? जैसे "कितना भाग्यशाली"? किराया / सवारी नहीं? यह संभव है और ऐसा ही है। तभी वे "आपको बिस्तर से उठा देंगे" और पूछेंगे कि "आप यहाँ क्या लिख ​​रहे हैं?"

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



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

इसके विपरीत, प्रोग्रामर के पास हमेशा "संदर्भ बिंदु" होते हैं। यहाँ मैंने एक परीक्षा लिखी। वह पास नहीं होता। यहां मैंने कार्यक्षमता को लागू किया। परीक्षा पास होने लगी।
मैंने सीवीएस / एसवीएन के लिए सब कुछ किया है। मैंने अपना काम किया और "मैं शांति से सो सकता हूं।"

टीडीडी - क्या ऐसा लग रहा है कि प्रोग्रामर लगातार उलटा समस्या हल कर रहा है? या डेवलपर एक डॉपेलगैंगर है, जो कार्य के समाधान को अनुकूलित करता है?

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

टीडीडी - दिखने वाले कांच के माध्यम से विकास। हमने परीक्षण किए कि त्रुटि-निर्दयता की कोई गारंटी नहीं है। परीक्षणों की गुणवत्ता के लिए कौन जिम्मेदार है?

पूर्ण त्रुटि-त्रुटि की कोई गारंटी नहीं है। केवल एक गारंटी है कि डेवलपर ने तकनीकी विशिष्टताओं को सही ढंग से समझा और जैसा उसने समझा था, उसे लागू किया।

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

यहाँ फिर से, चलो "सबसे वैज्ञानिक बहस।" हम उन शब्दों को परिभाषित करते हैं जो एक गाड़ी है और एक घोड़ा क्या है। और मुझे विकिपीडिया के साथ धमकी न दें (मैं जो नहीं कर सकता हूं वह कैसे जांच सकता है)?

यह सही होगा:
- "घोड़ा मास्टर" टीके है;
- "गाड़ी" एक कोड है।

और परीक्षण क्या हैं? टेस्ट "शाफ्ट" होते हैं, जिसके साथ घोड़ा गाड़ी से जुड़ा होता है। टीके की पूरी प्रक्रिया भाग्यशाली है, और परीक्षण कोड को साथ खींचते हैं और टीके के साथ इसके अनुपालन की जांच करते हैं। यह कोड TK के समान दिशा में जाता है। कोई टेस्टफर्स्ट नहीं है! न ही कोडफ़र्स्ट! एक TK-पहला है। लेकिन अगर सरलीकृत किया जाए। श्रृंखला इस तरह दिखती है: TK -> वास्तुकला की एक रूपरेखा -> परीक्षण -> कोड, और फिर विकल्प संभव हैं।

टीके -> वास्तुकला का स्केच -> टेस्ट -> कोड -> टेस्ट -> कोड
TK -> वास्तुकला का स्केच -> परीक्षण -> कोड -> वास्तुकला -> परीक्षण -> कोड
TK -> वास्तुकला का स्केच -> परीक्षण -> कोड -> वास्तुकला -> परीक्षण -> कोड -> TK -> वास्तुकला -> परीक्षण -> कोड
... आदि। आदि

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



वैसे, दुनिया में "परवरेट" हैं। फिर कम से कम आप दुख को कैसे कम कर सकते हैं? सही प्रक्रिया क्या है?

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

ठीक है, अब हम सही नहीं हैं, लेकिन सही डेवलपर्स हैं। एक घोड़े (छोटे पैरों के साथ एक जिद्दी परीक्षण टट्टू) और एक तरकश डो (डेवलपर के विचार) का दोहन कैसे करें?

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

हमारे द्वारा उपयोग किए जाने वाले उपकरण हैं:
- डनिट।
- ड्यूनीट में सुधार ;
- संगम ;
- JIRA का एक स्व-निर्मित एनालॉग; उस समय JIRA अभी भी "पनीर" था, इसलिए हमने इसे नहीं लिया; अब - मुझे लगता है - वे उसे ले जाएंगे;
- स्क्रिप्टिंग मशीन ;
- फिशई (https://www.atlassian.com/software/fisheye/overview);
- संघर्ष और FishEye में सुधार जो आपको कमिट, कोड परिवर्तन और विशिष्ट कार्यों में विशिष्ट कोड परिवर्तनों के बंधन का निर्माण करने की अनुमति देता है;
- यूएमएल और संगम का एकीकरण;



परीक्षण कौन बनाता है? और अगर परीक्षण निर्माता की "भूमिका" प्रोग्रामिंग का ज्ञान नहीं देती है?

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

क्या TDD हमारी "सब कुछ" है या क्या आप अभी भी इस तकनीक की सीमाओं को पहचानते हैं?

"यह सिर में है, कोड में नहीं।" कोई सीमा नहीं है। आवेदन करने की अनिच्छा है।

क्या TDD सभी प्रणालियों पर लागू होता है? क्या "विशेष मामले" या "अन्य दृष्टिकोण" हैं?

कोई "विशेष मामले" नहीं हैं। डेवलपर्स की इच्छा है कि वे "शांति से सोएं" और अपनी नसों को रखते हुए बहुत अधिक न सोचें।



कुछ ऐसा है जिसे टीडीडी से बाहर निकाला जा सकता है, कुछ ऐसा है जिसे अंदर लाया जा सकता है। लेकिन कुल मिलाकर, TDD बनी हुई है और कोई घबराहट की गारंटी नहीं है। आतंक-प्रेरित विकास को बाहर रखा गया है।

क्या आप TDD के लिए लाता है?

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

आपको क्या लगता है कि टीडीडी से बेहतर क्या हो सकता है?

BDD। डेल्फी की दुनिया में ऐसे लोग हैं जो ऐसा करते हैं और इसे बढ़ावा देते हैं। रोमन यांकोवस्की इस पर काम कर रहे हैं । अच्छी तरह से और फ़िट-टेबल। अगर विकसित होने की इच्छा है, तो आप खुद बहुत कुछ तक पहुंच सकते हैं। या आधा संकेत, स्केच लेख, विकिपीडिया (अंतिम उपाय के रूप में) का उपयोग करें। लेकिन आज मैंने वास्तव में काम करने की प्रक्रिया के बारे में बात की। मैं अपने ब्लॉग पर विस्तार से लिखता हूं, लेकिन दर्शकों के साथ संचार ने साबित किया है (पाठकों से परे) कि मुख्य समस्या टीडीडी के मूल्य को समझने में है। मैंने आज इस बारे में बात करने की कोशिश की।

कुछ भी नहीं है कि कुछ सवाल "ट्रोलिंग" की तरह लग रहे थे?

जीवन में, यह तब नहीं हुआ जब टीडीडी को उत्पादन प्रक्रिया में पेश किया गया था। सामान्य प्रतिक्रिया।