TDD और संस्करण नियंत्रण

Question

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

1. मैं एक नई परियोजना शुरू करता हूं और एक सरल परीक्षण लिखता हूं, जो कि अभी तक कोई भी नहीं है। क्या मुझे कक्षा लिखने से पहले परीक्षण करना चाहिए, हालांकि परीक्षण भी संकलन नहीं करता है? या क्या मुझे कमिट करने के लिए टेस्ट करने के लिए आवश्यक न्यूनतम कोड कोड को जमा करना चाहिए?

2. मैं एक बग ढूंढता हूं और इसे फिर से बनाने के लिए एक परीक्षण लिखता हूं। क्या मुझे फेलिंग टेस्ट करना चाहिए या बग फिक्स को लागू करना चाहिए और फिर कमिट करना चाहिए?

ये दो उदाहरण हैं जो तुरंत दिमाग में आते हैं। अपने उत्तर में अतिरिक्त उदाहरण देने के लिए स्वतंत्र महसूस करें।

संपादित करें:

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

इसका मतलब है कि मेरे सवाल के रूप में के बारे में ज्यादा के रूप में है क्या प्रतिबद्ध करने के लिए के रूप में इसके बारे में है जब प्रतिबद्ध करने के लिए।

Answer 1

क्या मुझे कक्षा लिखने से पहले परीक्षण करना चाहिए, हालांकि परीक्षण भी संकलन नहीं करता है? या क्या मुझे कमिट करने के लिए टेस्ट करने के लिए आवश्यक न्यूनतम कोड कोड को जमा करना चाहिए?

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

मैं एक बग ढूंढता हूं और इसे फिर से बनाने के लिए एक परीक्षण लिखता हूं। क्या मुझे फेलिंग टेस्ट करना चाहिए या बग फिक्स को लागू करना चाहिए और फिर कमिट करना चाहिए?

नहीं, असफल परीक्षा न करें। लेब्लांक का नियम बताता है:

बाद में कभी बराबरी नहीं हुई।

और आपका परीक्षण लंबे समय तक विफल हो सकता है। इसका पता चलते ही समस्या को ठीक करना बेहतर है।

इसके अलावा, TDD विकास शैली बताती है:

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

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

---

¹ जब मैंने कमिट किया, तो मेरा मतलब वास्तव में ट्रंक के लिए था (यूजर्स के लिए, अपने बदलावों को आगे बढ़ाएं, इसलिए अन्य डेवलपर्स उन्हें मिलेंगे)।

Comments

"और निश्चित रूप से एक ही परियोजना पर काम करने वाले लोगों को नाराज कर देगा" - अगर कोई SVN दुनिया में जीआईटी का उपयोग कर रहा है और आप किसी को भी गुस्सा नहीं करेंगे

— Mateusz

मुझे लगता है कि टेस्ट लिखने के बाद कमिट करना ठीक है, जब तक आप इसे पूरा नहीं कर लेते, तब तक इसे पुश न करें।

— मात्सेमन्न

@radarbob क्या यह डीवीसीएस के लिए भी लागू होता है जहां कमिटिंग और पुश करने में अंतर है? मैं ऐसी स्थिति की कल्पना कर सकता हूं, जहां मैं अपने स्थानीय गिट रेपो में कई कमिट करता हूं, जहां पर अंतिम रूप से बिल्ड टूटा नहीं है, लेकिन अंतरिम किसी भी समय यह हो सकता है।

— संहिता-गुरु

नहीं, असफल परीक्षा न करें। लेकिन टीडीडी के बिंदुओं में से एक कोडिंग से पहले एक असफल परीक्षण करना ठीक है। तो एक असफल परीक्षा शुरू करने से समझ में आता है।

— मौविसील

@ कोड-गुरु: एक डीवीसीएस के लिए, यह नियम होना चाहिए: "एक शाखा को टूटा हुआ कोड न दें जो दूसरों को नियमित रूप से खींचते हैं"। यदि अन्य आपके स्थानीय रेपो से नहीं खींचते हैं, तो वह आपके साथ रह सकने वाली किसी भी स्थिति में हो सकता है।

— बार्ट वैन इनगेन शेनौ

Answer 2

क्या मुझे कक्षा लिखने से पहले परीक्षण करना चाहिए, हालांकि परीक्षण भी संकलन नहीं करता है?

नहीं।

क्या मुझे असफल परीक्षा देनी चाहिए

नहीं।

आप यहां दो प्रतिमानों के बारे में बात कर रहे हैं:

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

मेरी अनुशंसा है: जब तक आपका कोड संकलित नहीं हो जाता, तब तक TDD के सर्कल का अनुसरण करें, आपके परीक्षण हरे हैं और आपको सिस्टम में योगदान करने के लिए कुछ मिला है। इसलिए आपको अपनी विशेषताओं को लंबवत रूप से काट देना चाहिए, जैसे कि एक नए UI मास्क के लिए संपूर्ण फ़ॉर्म न बनाएं और व्यावसायिक तर्क के बिना कमिट करें, बल्कि एक छोटे से पहलू को लागू करें, लेकिन साथ ही साथ व्यावसायिक तर्क के साथ-साथ दृढ़ता में परत ।

एक बड़े बगफिक्स के लिए, प्रत्येक सुधार (उदाहरण के लिए रिफैक्टरिंग) के बाद प्रतिबद्ध करें, भले ही बग अभी तक तय न हो। टेस्ट हरे होने चाहिए, और कोड को संकलित करना चाहिए, हालांकि।

Answer 3

निश्चित रूप से आप git जैसे स्वस्थ स्रोत नियंत्रण का उपयोग करके शुरू करते हैं।

फिर आप जिस तरह से काम कर सकते हैं, और प्रत्येक कोने पर कमिट कर सकते हैं - कोई भी कदम या सबपिप एक निष्पक्ष खेल है।

फिर सामान को धकेलने से पहले आप पूरे काम को एक कमिट में स्क्वैश करें। या एक युगल, उन बिंदुओं पर जहां सब कुछ हरा है और रचना समझ में आती है। और उन समझदार कामों को आगे बढ़ाएं। कई मामलों के लिए, इसे एक शाखा बनाएं जिसे आप --no-ff के साथ मर्ज करते हैं।

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

Answer 4

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

Comments

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

— Fil

Answer 5

क्या मुझे कक्षा लिखने से पहले परीक्षण करना चाहिए, हालांकि परीक्षण भी संकलन नहीं करता है?

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

या क्या मुझे कमिट करने के लिए टेस्ट करने के लिए आवश्यक न्यूनतम कोड कोड को जमा करना चाहिए?

आपके ऊपर (git आपको अपनी टीम के अन्य सदस्यों, या विभिन्न विशेषताओं पर काम करने की आपकी क्षमता को प्रभावित किए बिना पसंद करने के लिए आपको लचीलापन देता है)। बस यह सुनिश्चित करें कि आपके पास एक ही समय में एक ही शाखा में एकाधिक अपूर्ण (गैर-कार्यशील) सुविधाएँ नहीं हैं (तब वे एक दूसरे को अवरुद्ध करेंगे)।

मैं एक बग ढूंढता हूं और इसे फिर से बनाने के लिए एक परीक्षण लिखता हूं। क्या मुझे फेलिंग टेस्ट करना चाहिए या बग फिक्स को लागू करना चाहिए और फिर कमिट करना चाहिए?

मैं आमतौर पर इसके लिए दो कमिट करता हूं, जब तक कि टेस्ट कोड लिखने के लिए वास्तव में छोटा / तुच्छ न हो।

ये दो उदाहरण हैं जो तुरंत दिमाग में आते हैं। अपने उत्तर में अतिरिक्त उदाहरण देने के लिए स्वतंत्र महसूस करें।

संपादित करें:

मैंने दोनों उदाहरणों में एक धारणा बनाई कि मैं परीक्षण लिखने के तुरंत बाद परीक्षण पास करने के लिए कोड लिखूंगा।

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

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

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

Comments

Git reset --hard की अनुशंसा करने में सावधानी बरतें। यह git के कुछ कमांड्स में से एक है जो आपको लूज वर्क का कारण बनेगा।

— gnash117

Answer 6

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

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

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