जब परीक्षणों में लंबा समय लगता है तो ट्रंक को स्थिर कैसे रखा जाए?


9

हमारे पास परीक्षण सूट के तीन सेट हैं:

  • एक "छोटा" सुइट, जिसे चलाने में केवल कुछ घंटे लगते हैं
  • एक "मध्यम" सुइट जिसमें कई घंटे लगते हैं, आमतौर पर हर रात (रात)
  • एक "बड़े" सुइट जो चलाने के लिए एक सप्ताह + लेता है

हमारे पास छोटे परीक्षण सूट का एक गुच्छा है, लेकिन मैं यहां उन पर ध्यान केंद्रित नहीं कर रहा हूं।

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

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

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

और इससे कोई फर्क नहीं पड़ता कि यह SVN की तरह एक केंद्रीकृत स्रोत नियंत्रण प्रणाली है या एक वितरित git जैसा है?

वैसे मैं चीजों को बदलने की सीमित क्षमता वाला एक जूनियर डेवलपर हूं, मैं सिर्फ यह समझने की कोशिश कर रहा हूं कि क्या इस दर्द को संभालने का कोई तरीका है जो मैं अनुभव कर रहा हूं।


6
मुझे पता नहीं है कि आप किस सॉफ्टवेयर पर काम कर रहे हैं, लेकिन एक छोटा परीक्षण सूट जो चलाने में घंटों लेता है वह कुछ डब्ल्यूटीएफ है। यदि वे तेजी से भागेंगे तो यह आसान होगा, आपके परीक्षणों को कारगर बनाने का कोई तरीका नहीं?
बेंजामिन बन्नियर

2
ट्रंक अस्थिर होने के बारे में इतना "बहुत कष्टप्रद" क्या है? यदि आप जानते हैं पता नहीं है, लेकिन सबसे लोकप्रिय में से एक शाखाओं में रणनीति भी कहा जाता है अस्थिर ट्रंक
कुटकी

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

1
... हम्म, आपका बेहतर विकल्प परीक्षणों और एप्लिकेशन लॉगिंग में सुधार करने की संभावना है ताकि विफलता का कारण ढूंढना आसान हो। इस तरह, किसी को "जासूसी जांच" पर प्रयासों को बर्बाद करने के बजाय विफलता का कारण खोजने और ठीक करने की आवश्यकता होगी , जो विशेष, कोड की विशेष पंक्ति को किसने, कब और क्यों बदला ...
gnat

1
@ हॉनक कुछ परीक्षणों को चलने में लंबा समय लगता है। मैं एक कंपनी के लिए काम करता हूं जो डेटा अधिग्रहण उपकरण बनाती है और हमारे "आंशिक" टेस्ट रन में लगभग एक घंटे लगते हैं। परीक्षणों के लिए विभिन्न प्रकार के मापन करने की आवश्यकता होती है और बस समय लगता है।
वेलोसाइराप्टर्स

जवाबों:


1

अस्थिरता के मूल कारण को ठीक करने का एकमात्र तरीका कोड को डिकूप करना है ताकि परिवर्तन अधिक पृथक हों, जैसा कि अन्य उत्तरों ने सुझाव दिया है।

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

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

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


1
-1 शाखाओं से काम करना व्यवहार्य विकल्प है, लेकिन परीक्षण के सुझाव के बिना इसकी सिफारिश करना अच्छे से अधिक नुकसान कर सकता है। केवल परीक्षण यह दिखा सकता है कि यह विशिष्ट परियोजना के लिए संभव है या नहीं। जैसे एक परियोजना में मैंने लगभग 2 साल पहले किया था, इस तरह के एक परीक्षण ने शाखाओं से काम करना दिखाया है ~ अस्थिर ट्रंक की तुलना में ~ 7x गुना अधिक प्रयास ले रहा था
gnat

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

12

मुझे पता है कि आप इससे बचने की कोशिश कर रहे हैं, लेकिन यहां वास्तविक अंतर्दृष्टि यह महसूस करने की है कि आपके कोडबेस के साथ कुछ गंभीर है: आपको परीक्षणों का एक पूरा सूट चलाने की ज़रूरत है, जिसमें एक सप्ताह लगता है कि आपका कोड स्थिर है!

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

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

आपके VCS संरचना के फ़्लिपसाइड प्रबंधन पर और अधिक जटिल हो जाएगा, लेकिन आपके पूर्ण परीक्षण के लिए एक पूर्ण सप्ताह में, मुझे लगता है कि आप दर्द उठा सकते हैं!

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


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

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

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

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

1

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

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

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


1

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


मैं यहां ज्यादातर कार्यप्रणाली के बारे में पूछ रहा हूं - यानी, ऐसी स्थिति से निपटने का एक सामान्य तरीका है। चलिए मान लेते हैं, कम से कम इस चर्चा के लिए, कि जो पहले से ही हैं उससे परे परीक्षणों को अनुकूलित नहीं किया जा सकता है।
ओक

@ ऑक: यहां किसी ने (आप?) ने मेरे जवाब को वोट दिया - लेकिन कभी-कभी जो चीजें आप नहीं सुनना चाहते हैं, वे ही चीजें हैं जो मदद करेंगी। जैसा कि आप अपने प्रश्न के नीचे चर्चा में देखते हैं, दूसरों ने भी यही सुझाव दिया है, इसलिए मेरा सुझाव इतना बुरा नहीं लगता।
डॉक्टर ब्राउन

+1, यह सही उत्तर है। ओपी का असली सवाल है "मदद करो, मैं बकवास में डूब रहा हूं, मैं अपनी मदद करने के लिए किस पद्धति का उपयोग कर सकता हूं?" और जवाब यह है कि वास्तव में कार्यप्रणाली वह नहीं है जिसके बारे में आपको चिंता होनी चाहिए।
MrFox

1

असफल माध्यम परीक्षण: क्या यह सच है कि ज्यादातर समय एक ही परीक्षण विफल हो जाते हैं?

यदि कोई विफलता है तो क्या हमेशा वही संबंधित परीक्षण विफल होते हैं?

यदि सही है: हो सकता है कि आप चुनिंदा माध्यमों को चुन सकते हैं जो अक्सर विफल हो जाते हैं (हर वर्ग की त्रुटि के लिए एक परीक्षा) और उन्हें छोटे सेट के भीतर निष्पादित करें।

क्या अधिकांश परीक्षण एकीकरण-परीक्षण हैं जो एक वास्तविक डेटाबेस का उपयोग करते हैं? यदि ऐसा है तो उन्हें एक unittest के साथ प्रतिस्थापित करना संभव है जिसमें एक नकली डेटाबेस है?


1

आपको अपने परीक्षण तेजी से चलाने की आवश्यकता है, इस सर्कल को चौकोर करने का कोई अन्य तरीका नहीं है।

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

यहाँ मेरा सुझाव है:

1) परीक्षण को यथासंभव परमाणु बनाएं, और पर्यावरण के पुन: उपयोग को अधिकतम करें।

2) उन्हें चलाने के लिए एक परीक्षण-सूट फार्म प्राप्त करें। यदि आप 8 बड़े मॉड्यूलों को समाप्त करते हैं, तो आप 50 के साथ समाप्त हो जाते हैं, आप अमेज़ॅन ईसी 2 स्पॉट इंस्टेंस का एक गुच्छा बना सकते हैं और पूरे सूट को समानांतर में चला सकते हैं। मुझे यकीन है कि इससे कुछ पैसे खर्च होंगे, लेकिन यह डेवलपर की बड़ी मात्रा को बचाएगा।


0

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

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

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

या आप बेतुके सादगीपूर्ण हो सकते हैं और एक स्क्रिप्ट है जो एक पाठ फ़ाइल में पासिंग कमिट्स को सूचीबद्ध करता है (जो स्वयं नियंत्रित नहीं हो सकता है)।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.