2010-07-27 5 views
10

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

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

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

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

आप मेरे जूते में क्या करेंगे?

पीएस .: मुझे stackoverflow पर एक समान प्रश्न के बारे में पता है, लेकिन इस में, लक्ष्य विभिन्न हितधारकों और निष्कासन के लिए सबसे अच्छा मार्ग मनाने के लिए है; एक तकनीकी तुलना नहीं।

+0

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

उत्तर

10

लगता है जैसे आपके पास स्थिति पर एक बहुत अच्छा संभाल है।

दो बातें:

  1. उम्मीद मत कीजिए पूरी तरह से इकाई परीक्षण एक 5 वर्षीय परियोजना के लिए सक्षम होने के लिए। 5 साल के लिए काम कर रहे 5 डेवलपर्स मानते हुए, आप 50,000 प्रोग्रामर-घंटे के पड़ोस में हैं। यह मानते हुए कि परीक्षण कोड के रूप में लिखने में उतना समय लगता है, आप एक वर्ष में 2-3% कवरेज प्राप्त करने के लिए बहुत अच्छा कर रहे होंगे।

  2. तो: नए कोड का परीक्षण करें, और पुराने कोड के संशोधनों के लिए परीक्षण लिखें। किसी प्रकार की सीआई स्थापित करने के लिए समय/समय निकालें। धीरे-धीरे, आप परीक्षणों की एक अच्छी बैटरी तैयार करेंगे।

चूंकि आप स्पष्ट रूप से बग में डूब नहीं रहे हैं, धीमी गति से शुरू करें, गति प्राप्त करें।

+1

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

+4

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

+1

@ वारुन - किसी को संक्रमित परीक्षण प्राप्त करने का सबसे अच्छा तरीका यह है कि यूनिट परीक्षण अपने गधे को कुछ बार बचाए। ऐसा करने का एकमात्र तरीका यह है कि यदि वे वास्तव में कुछ परीक्षण लिखते हैं: पी यूनिट परीक्षण से अपरिचित कई डेवलपर्स ऐसा नहीं करते हैं क्योंकि वे नहीं जानते कि क्या करना है। उन्हें अच्छे उदाहरण दिखने के कुछ उदाहरण दें, और उन्हें कितना आसान लिखना है, और वे चारों ओर आ जाएंगे। – Seth

2

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

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

+0

समस्या यह है कि, मैं चाहता हूं कि बाकी टीम भी परीक्षा लिखना शुरू कर दे, और संभवत: इसके मूल्य को देखने के लिए। कम से कम प्रतिरोध के पथ को खोजने की कोशिश कर रहा है। –

+0

आप उदाहरण के आधार पर नेतृत्व कर सकते हैं, कुछ परीक्षण लिखकर शुरू कर सकते हैं और फिर, क्योंकि वे प्रतिक्रियाओं को ट्रैक करने में मदद करते हैं, उन्होंने आपके द्वारा सहेजे गए समय के बारे में दावा करते हैं।;) – thomasrutter

1

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

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

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

0

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

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

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

0

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

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

0

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

संबंधित मुद्दे