यूनिट परीक्षणों के लिए एक नया नाम [बंद]


9

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

अब मुझे यूनिट टेस्ट पसंद हैं क्योंकि वे मुझे उपयोगी कोड लिखने की अनुमति देते हैं, जो कि अक्सर पहली बार काम करता है! (लकड़ी पर दस्तक)

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

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

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

क्या मैं दरार पर हूं या कोई और इस परीक्षण को करने से इनकार करता है और क्या उन्हें लगता है कि यह एक ऐसा ही कारण है जो वे इसे नहीं करना चाहते हैं?
परीक्षण न करने के लिए आप / अन्य क्या कारण देते हैं?
आपको क्या लगता है कि उनकी प्रेरणाएँ इकाई परीक्षण में नहीं हैं?

और इकाई परीक्षण के लिए एक नए नाम के रूप में जो कुछ आपत्तियों पर प्राप्त हो सकता है, jContract के बारे में कैसे? (थोड़ा जावा केंद्रित मुझे पता है :), या यूनिट कॉन्ट्रैक्ट्स?


14
नाम में क्या है? जिसे हम गुलाब कहते हैं, किसी भी अन्य नाम से मिठाई के रूप में गंध आती है; - शेक्सपियर, रोमियो और जूलियट, c.1600
स्टीवन ए लोव

8
मुझे नहीं पता कि आप दरार पर हैं। मैंने कभी दरार की कोशिश नहीं की, या आप होने के नाते।
टिम पोस्ट

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

2
अनुबंध द्वारा डिजाइन: en.wikipedia.org/wiki/Design_by_contract एक विशिष्ट अनुमान है, और इकाई परीक्षण यह है। अगर मुझे नाम में कॉन्ट्रैक्ट के साथ कुछ दिखाई देता है, तो वह (और इंटरफेस) वह है जो मेरा मस्तिष्क इसके साथ जुड़ा हुआ है।
बेरिन लोरिट्श

@ स्टीव 314 स्कोपी। पसंद है। :) मुझे लगता है कि इस मामले में, शब्द परीक्षण पहले से ही परिभाषित है, और इस प्रकार इकाई परीक्षणों को अपरिभाषित शब्द में बदलना बेहतर होगा। अनुबंधित 'इंटरफ़ेस' के कारण यह नहीं हो सकता। कैसे 'बेहतर कार्यक्रम तेजी से बनाएं' या सीबीपीएफ के बारे में।
विल

जवाबों:


5

क्या मैं दरार पर हूं या कोई और इस परीक्षण को करने से इनकार करता है और क्या उन्हें लगता है कि यह एक ऐसा ही कारण है जो वे इसे नहीं करना चाहते हैं?

यूनिट टेस्टिंग में वर्ड टेस्टिंग लोगों को लगता है कि यह इंटीग्रेशन टेस्टिंग या यूजर इंटरफेस टेस्टिंग है, क्योंकि यही एकमात्र टेस्ट है जो उन्होंने कभी किया है। यह जावा को जावास्क्रिप्ट में डालना पसंद करता है।

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

परीक्षण न करने के लिए आप / अन्य क्या कारण देते हैं?

वे निर्भरताएँ जिनका नकली / नकली होना मुश्किल है

आपको क्या लगता है कि उनकी प्रेरणाएँ इकाई परीक्षण में नहीं हैं?

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


शानदार अंक। यह समझाने की कोशिश करना कि आप एक सरल विधि प्राप्त करने के लिए 'परीक्षण' क्यों करेंगे, यह समझाना कठिन है कि आपके बाकी सभी कोडों की स्थिरता के लिए यह क्यों महत्वपूर्ण है कि प्राप्त विधि हमेशा वही देती है जो आप उम्मीद करते हैं कि बनाने के लिए एक आसान तर्क है
विल

3

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

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


2
निष्पादन योग्य विनिर्देश संभवतः TDD / BDD / Agile / XP से पूर्ववर्ती हैं। यह सीएमएमआई जितना पुराना हो सकता है। यह यूएमएल के साथ एक सह-सनक हुआ करता था जब लोग सोचते थे कि ईएमएल ईएस लिखने के लिए भाषा है।
11'11

BDD, जैसे TDD, परीक्षण का एक दृष्टिकोण है, न कि एक प्रकार का परीक्षण (कार्यात्मक v एकीकरण v यूनिट v स्वीकृति)। लेखक विशेष रूप से इकाई परीक्षण के लिए "बेहतर" नाम के बारे में पूछ रहा है।
यबकोस

0

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

मुझे लगता है, आप की तरह, कि ज्यादातर लोग परीक्षण करने के लिए अनिच्छुक हैं क्योंकि वे सोचते हैं कि यह अधिक काम है और कोई फायदा नहीं है।


0

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

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

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

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


आपको बहुत सरल कोड लिखना होगा। अधिकांश आधुनिक प्रणालियों में पहुंच योग्य राज्यों की मात्रा का मतलब है कि अंत-टू-एंड परीक्षण करना ब्रह्मांड के जीवनकाल को ले जाएगा - प्रत्येक राज्य के 4बिट्स के साथ दो टुकड़ों का परीक्षण प्रत्येक के परीक्षण के लिए 16 मामले लेता है, या कुल 32 परीक्षण मामले; एंड-टू-एंड सिस्टम में बनाया गया 8 स्टेट्स या 256 टेस्ट केस सभी राज्यों को कवर करता है। व्यक्तिगत रूप से, मैं काम 1/8 करूँगा।
पीट किर्कम

1
@PeteKirkham इस बात की पुष्टि करता है कि आपको बड़ी संख्या में इकाई परीक्षण लिखने की आवश्यकता है और फिर यह सुनिश्चित करने के लिए एकीकरण परीक्षण भी लिखें कि इकाई अभी भी एक दूसरे के साथ काम करती है। जिन जगहों पर मैंने काम किया था, वे यूनिट परीक्षणों के बहुत शौकीन थे, उन्हें लिखने में (और बनाए रखने में) इतना समय लगा दिया कि उन्होंने कोडबेस को बौना कर दिया, और उस वातावरण की तुलना में मैंने जो काम किया, उसकी तुलना में उनके काम की मात्रा बहुत कम थी। कुछ भी नहीं एक जादू की गोली है, मैं एक और अधिक व्यावहारिक दृष्टिकोण खोजने की कोशिश करने की सलाह देता हूं जो आपको कुछ उत्पादन करते समय महत्वपूर्ण बिट्स के दोनों परीक्षण कवरेज देता है।
gbjbaanb
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.