परीक्षण संचालित विकास - परीक्षणों को किसको लिखना चाहिए?

Question

मूल रूप से, यह परीक्षण लिखने के लिए डेवलपर का कर्तव्य है, लेकिन मैंने देखा कि कई मामलों में / ई-परिपक्व डेवलपर्स उन मामलों को 80% कवरेज भी नहीं दे रहे हैं।
कैसे के बारे में मैं एक क्यूए व्यक्ति डेवलपर के बजाय एक दिया परियोजना के लिए सभी परीक्षण लिखने के लिए समर्पित है?
क्या उस पर कोई सहमति है?

Comments

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

— आरोन मैकिवर

Answer 1

टेस्ट-प्रेरित विकास में, परीक्षण डेवलपर द्वारा लिखे जाने चाहिए। अन्यथा डेवलपर के अलावा कोई अन्य व्यक्ति विकास चला रहा है।

इसलिए जैसे ही आप किसी गैर-डेवलपर को परीक्षण लिखने का काम देते हैं, वह व्यक्ति डेवलपर बन जाता है।

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

Comments

यदि आपके पास कौशल-सेट रुख से दो तरह के दिमाग वाले व्यक्ति हैं, तो आप यकीनन TDD को परीक्षण और कोड के बीच स्वैपिंग / जोड़ी प्रोग्रामिंग तरीके से कर सकते हैं। उन्हें परीक्षक / प्रोग्रामर / कोड बंदर कहें ... यह किसी के कौशल सेट के बारे में है जैसा कि आपने स्पर्श किया था।

— एरोन मैकिवर

और यह देखते हुए कि आप लिख रहे हैं_टैस्ट-राइट_कोड-रन_टेस्ट संभवत: हर मिनट आप अपनी प्रगति की दर को कम कर देंगे।

— फ्रैंक शीयर

Answer 2

क्यूए का काम पूरी तरह से अलग तरह का परीक्षण (यानी प्रयोज्य / एकीकरण परीक्षण) करना है। उन्हें वास्तव में कोड में उपयोग की जाने वाली तकनीकों का ज्ञान नहीं है।

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

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

Answer 3

वे मामले 80% कवरेज भी नहीं दे रहे हैं

यह एक प्रबंधन समस्या हो सकती है।

या यह अप्रासंगिक हो सकता है।

सबसे पहले, 80% और 100% कवरेज के बीच का अंतर शायद बहुत कम लाभ के लिए बहुत अधिक लागत है।

"कवरेज" का मतलब कुछ भी हो सकता है। कोड की लाइनें, तर्क पथ, आदि। मैं आपको कोड की लाइनें (तर्क पथ नहीं) का मतलब लगा रहा हूं।

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

20% अधिक परीक्षण हमेशा 20% अधिक गुणवत्ता वाला नहीं होता है।

दूसरा। यह एक प्रबंधन समस्या है। यदि प्रबंधन 100% कवरेज चाहता है, तो उन्हें "% जारी करने के लिए पर्याप्त" के बजाय 100% कवरेज को पुरस्कृत करने के लिए एक इनाम प्रणाली डालनी होगी।

अधिक परीक्षण लिखने के लिए क्यूए लोगों को जोड़ने से बहुत मदद नहीं मिलेगी।

अधिक परीक्षण लिखने के लिए डेवलपर्स को जोड़ना 100% परीक्षण कवरेज प्राप्त करने के लिए आवश्यक होगा।

Comments

100% कवरेज के बारे में किसने कुछ कहा?

— एरिक विल्सन

@FarmBoy: सवाल यह है कि 80% कवरेज काफी अच्छा नहीं है। क्या काफी अच्छा है? सामान्य जादुई संख्या 100% कवरेज है।

— S.Lott

लेकिन मेरे कोच ने हमेशा मुझे 110% देने की बात कही। मुझे कवरेज की इतनी मात्रा की आवश्यकता क्यों नहीं हो सकती ... --P

— बेरिन लोरिट्श

@ बेरिन लोरिट्स: मैं आपके पीछे 200% हूं।

— एस.लॉट

@ जोब: "कुछ क्यूए लोग कुछ कोड लिख सकते हैं"। सही। फिर वे डेवलपर्स बन जाते हैं, जो अच्छी बात है।

— S.Lott

Answer 4

IMHO इकाई परीक्षण एक QA प्रक्रिया नहीं है। यह विकास को गति देने (डेवलपर्स के लिए फीड बैक लूप को सिकोड़कर) के बारे में अधिक है। यह घटक उपयोग (किसी अन्य डेवलपर द्वारा) पर ध्यान देने के साथ घटक (उर्फ इकाई) लिखने वाले व्यक्ति द्वारा किया जाना चाहिए।

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

दोनों एक टीडीडी फैशन में किया जा सकता है।

Answer 5

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

आपको यह भी ध्यान रखना चाहिए कि कवरेज आपको कोड गुणवत्ता के बारे में नहीं बताएगा और यह नहीं बताएगा कि डोमेन नियम कवर किए जा रहे हैं या नहीं।

Answer 6

यदि आपको कम से कम 80% कवरेज की आवश्यकता है, तो आपको कुछ चीजें करने की आवश्यकता है:

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

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

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