हाल ही में, हमारी कंपनी में एक इंजीनियरिंग इंजीनियरिंग व्याख्यान आयोजित किया गया था और यह टीडीडी के लिए एक परिचय बन गया।
अरे नहीं, ऐसा नहीं है! "कभी-कभी वे वापस आ जाते हैं" (सी) स्टीफन किंग
पिछले काम में, हमने इस तकनीक को लागू करने की कोशिश में 3 साल लगा दिए। यह दर्दनाक था। प्रबंधन का ईमानदारी से मानना था कि टीडीडी कंपनी की समस्याओं को हल करेगा। हकीकत इस के साथ हड़ताली असंगत था। यह सब सोवियत काल की यादों को जगाता है। मैंने पोस्टरों को याद किया "फॉरवर्ड ऑफ़ विक्ट्री ऑफ़ कम्युनिज़्म" दीवारों और वाक्यांशों पर लटका हुआ है जैसे "मार्क्स का सिद्धांत सर्वव्यापी है क्योंकि यह सच है।"
तो क्या TDD
कंजर्वेटरी के साथ गलत है?
त्याग
दुर्भाग्य से, मेरी पोस्ट को कई लोगों ने इस अर्थ में समझा था कि मैं परीक्षण के खिलाफ हूं। और विशेष रूप से उनके सभी अभिव्यक्तियों में इकाई परीक्षणों के खिलाफ। यह पूरी तरह सच नहीं है, या यह बिल्कुल भी नहीं है।
मैं यहां एक महत्वपूर्ण टिप्पणी की प्रतिलिपि बनाता हूं, जो पोस्ट के अंत में थी और यह बहुत हड़ताली नहीं थी।
यूनिट परीक्षण बहुत उपयुक्त होने पर 3 प्रकार के कोड होते हैं और उनका उपयोग उचित है:
- उच्च विश्वसनीयता सॉफ्टवेयर - उदाहरण के लिए, हवाई जहाज, बिजली संयंत्रों आदि के लिए सॉफ्टवेयर।
- आसानी से पृथक कोड - एल्गोरिदम और वह सब
- उपयोगिताएँ - कोड जो बहुत व्यापक रूप से सिस्टम में उपयोग किया जाएगा, इसलिए यह पहले से उन्हें अच्छी तरह से चमकाने लायक है
यदि आपके लिए यूनिट टेस्ट लिखना आसान और सरल है, जिसका अर्थ है कि आपका कोड आसानी से अलग-थलग है, तो आपको आगे नहीं पढ़ना होगा और मेरे अनुभव में तल्लीन होना चाहिए, जो दर्द, पसीने और खून से चोटिल हुआ है। ठीक है, यदि नहीं, तो ध्यान रखें कि निम्नलिखित एक विशेष रूप से एकल मामला है, लेकिन यह पीड़ित और सार्थक है।
शुरुआत के लिए, आइए शर्तों को परिभाषित करें।
शब्दावली
मैनुअल परीक्षणकार्यक्षमता को "लाइव" सिस्टम पर मैन्युअल रूप से परीक्षण किया जाता है, इसके लिए मानक UI का उपयोग किया जाता है।
यह क्यूए के लिए एक आम, पारंपरिक परीक्षण विधि है।
कार्यात्मक परीक्षणप्रोग्रामर कुछ प्रकार के "परीक्षण" यूआई लिखता है, जो आपको इन मॉड्यूल की बातचीत के साथ एक "लाइव" सिस्टम पर कुछ स्क्रिप्ट चलाने की अनुमति देता है।
यह प्रोग्रामर्स द्वारा उपयोग की जाने वाली एक बहुत ही सामान्य परीक्षण विधि है।
इकाई परीक्षणप्रोग्रामर ऐसे परीक्षण लिखता है जो अन्य मॉड्यूल के बिना - "पृथक" वातावरण में चलने में सक्षम हैं। अन्य मॉड्यूल जिनमें ऑपरेशन के दौरान परीक्षण किए गए कोड को लागू करना चाहिए, उन्हें मोक्स द्वारा प्रतिस्थापित किया जाता है। इस प्रकार, संकलन के बाद परीक्षणों का निर्माण स्वचालित रूप से किया जा सकता है।
इस तरह के परीक्षणों का उपयोग करने के लिए एक प्रवृत्ति है। और प्रोग्रामर दबाव में हैं (नैतिक और प्रशासनिक) ताकि उनके उपयोग पर स्विच किया जा सके।
TDD के बारे में अलग से नोटटीडीडी एक प्रोग्रामिंग तकनीक है जो इकाई परीक्षणों का व्यापक उपयोग करती है। और अगर यूनिट परीक्षणों में कुछ गड़बड़ है, तो टीडीडी परेशानी जोड़ सकता है (जो वह सफलतापूर्वक करता है), लेकिन किसी भी तरह से इसे कम न करें।
"कोड में त्रुटि"कोड एक त्रुटि के साथ लिखा गया है और प्रोग्रामर के इरादे से अलग कुछ करता है।
"एकीकरण त्रुटियाँ"दो प्रोग्रामर ने इंटरेक्टिंग मॉड्यूल / कक्षाएं लिखीं, और प्रोटोकॉल को गलत समझा। प्रोटोकॉल फ़ंक्शन को दिए गए दोनों मापदंडों और कॉल के सही / वैध अनुक्रम को संदर्भित करता है।
इसके अलावा, प्रत्येक वर्ग को "सफाई से" लिखा जा सकता है, लेकिन जब उन्हें एक साथ रखा जाता है तो वे सिस्टम का सही संचालन करते हैं।
"बहुउद्देशीय और समय त्रुटियाँ"यदि कई थ्रेड कार्य में भाग लेते हैं, तो साझा संसाधन तक पहुंच से संबंधित या कॉल के अनुक्रम में त्रुटियां संभव हैं। ये सबसे मायावी (स्मृति भ्रष्टाचार के बाद) बग हैं जिनका मैंने सामना किया है।
यूआई त्रुटियां और अनफ़ेयरसेन त्रुटियांयूआई आवश्यकताओं को पूरा नहीं करता है या किसी न किसी तरह से कुछ विशिष्ट परिस्थितियों में कुटिल प्रक्रियाओं को पूरा करता है।
मान लें कि यह गलत डेटा के इनपुट की अनुमति देता है या नकारात्मक परिणाम के मामले में पर्याप्त स्पष्ट संदेश प्रदर्शित नहीं करता है।
विभिन्न प्रकार के परीक्षण के पेशेवरों और विपक्ष
| गाइड | कार्यात्मक | इकाई |
|---|
| "कोड में त्रुटियों" को खोजने की क्षमता | हां | हां | हां |
| "एकीकरण त्रुटियों" को खोजने की क्षमता | हां | हां | नहीं |
| "बहुउद्देशीय और समय त्रुटियों को खोजने की क्षमता" | आंशिक रूप से | आंशिक रूप से | नहीं |
| "UI त्रुटियों" और "आकस्मिक त्रुटियों" को खोजने की क्षमता | हां | आंशिक रूप से | नहीं |
| विभिन्न प्रकार के इनपुट के साथ परीक्षण करने की क्षमता | कम | स्वीकार्य | बहुत ऊँचा |
| परीक्षण को स्वचालित करने की क्षमता | बहुत कम | कम | हां |
| अतिरिक्त प्रोग्रामिंग प्रयास | नहीं | नहीं ... X1.5 | x2 ... x5 |
मेरे अनुभव के अनुसार (मेरे पास सटीक आंकड़े नहीं हैं, दुर्भाग्य से), "कोड में त्रुटियां" एक जटिल प्रणाली में सभी बगों के 30% से कम के लिए जिम्मेदार हैं। यदि प्रोग्रामर को पर्याप्त अनुभव किया जाता है, तो ऐसी त्रुटियों की संख्या और भी कम होगी।
इस तरह की त्रुटियों का बड़ा हिस्सा पूरी तरह से "कोड समीक्षा" (कोड समीक्षा) और कार्यात्मक परीक्षणों का उपयोग करके पकड़ा जाता है।
इकाई परीक्षण विभिन्न संभावित विकल्पों के साथ कोड का परीक्षण करने में सक्षम हैं, सभी कल्पनीय इनपुट डेटा के ठीक नीचे। आप बहुत सावधानी से कोड का परीक्षण कर सकते हैं, आप "अंतिम कोमा में" भी कर सकते हैं।
समस्या यह है कि स्थितियों का एक निश्चित सेट है जो वास्तविक प्रणाली में हो सकता है। इस सेट से परे कुछ परीक्षण करना अप्रासंगिक और समय की बर्बादी है।
कार्यात्मक परीक्षण आमतौर पर संभावित परिस्थितियों के एक पूरी तरह से "तर्कसंगत" सेट को कवर करते हैं।
यूनिट परीक्षणों की सबसे बड़ी ताकत स्वचालन है।
लेकिन यहां मैं व्यक्तिगत रूप से (3 साल से अधिक काम) एक ऐसी स्थिति में नहीं आया था, जहां इकाई परीक्षणों ने इसे लिखने के काफी समय बाद बग को खोजने में मदद की।
अर्थात्, इकाई परीक्षण प्रभावी (बग्स को खोजने में मदद करने वाले) लिखने के बाद असाधारण रूप से कम समय के होते हैं।
मैंने कभी भी किसी बिल्डर को किसी चीज को पकड़ने के लिए यूनिट टेस्ट को अपने आप चलाते नहीं देखा। वे वहां "क्लीन क्लीन" करते हैं। ठीक है, निश्चित रूप से, नेतृत्व की मन की शांति की सेवा करें। :)
यूनिट टेस्ट का माइनस बहुत बड़ा प्रयास है जिसे लिखने और प्रोग्रामिंग मोक पर खर्च करना पड़ता है। यही कारण है कि यूनिट परीक्षणों का उपयोग करते हुए विकास के लिए आवश्यक समय उनके बिना 2-5 गुना अधिक है।
बेशक, यदि कोड अन्य मॉड्यूल का कम उपयोग करता है, इसलिए इसे पूरी तरह से अलग करना बहुत आसान है, तो यूनिट परीक्षण लगभग कार्यात्मक परीक्षणों के साथ ओवरलैप करता है और उनके बीच का अंतर केवल नाम और मामूली तकनीकी विवरण में है।
सारांश:यूनिट परीक्षण प्रणाली की विश्वसनीयता में महत्वपूर्ण लाभ नहीं देते हैं।
यूनिट परीक्षण बहुत उपयुक्त होने पर 3 प्रकार के कोड होते हैं और उनका उपयोग उचित है:
- उच्च विश्वसनीयता सॉफ्टवेयर - यहां कोई लागत नहीं है
- आसानी से पृथक कोड - इकाई परीक्षण लिखना आसान, सरल है, और उनकी लागत कार्यात्मक परीक्षणों से अधिक नहीं है
- उपयोगिताएँ - कोड जो बहुत व्यापक रूप से सिस्टम में उपयोग किया जाएगा, इसलिए यह पहले से उन्हें अच्छी तरह से चमकाने लायक है
अन्य सभी मामलों में, यूनिट परीक्षणों की इकाई लागत / लाभ अनुपात कम है। यूनिट बग (विशेष रूप से, कोड निरीक्षण) का उपयोग करके पकड़े जाने वाले उन बगों से निपटने के बहुत सस्ते तरीके हैं।
यदि किसी त्रुटि की लागत बहुत अधिक है (उदाहरण के लिए, हम एक हवाई जहाज या पावर प्लांट के लिए सॉफ्टवेयर लिखते हैं), तो, निश्चित रूप से, कोई भी लागत अत्यधिक नहीं है और इकाई परीक्षणों का उपयोग किया जाना चाहिए। लेकिन आमतौर पर त्रुटि की लागत बहुत कम होती है।
संगठनात्मक और मनोवैज्ञानिक क्षण
बैकफ़िल प्रश्न: कौन और कैसे सुनिश्चित कर सकता है कि प्रोग्रामर ने यूनिट परीक्षणों को अच्छी तरह से लिखा है?
यूनिट परीक्षणों की जाँच के लिए दो संभावित विकल्प हैं:
वाद्य यंत्र की जाँचपरीक्षणों के साथ कोड की "कवरेज" को मापना संभव है - क्या परीक्षणों के हिस्से के रूप में कोड की सभी पंक्तियों को निष्पादित किया गया था। मैंने इस तरह के चेक का इस्तेमाल कभी नहीं देखा। ठीक है, निश्चित रूप से, ऐसे परीक्षण सत्यापित कर सकते हैं कि परीक्षण कोड को "कवर" करते हैं, लेकिन वे यह सत्यापित नहीं कर सकते कि परीक्षण संभव इनपुट "कवर" करते हैं।
एक अन्य प्रोग्रामर या पर्यवेक्षक द्वारा यूनिट परीक्षण निरीक्षणमैंने देखा कि यह कैसे किया जाता है। लेखन इकाई परीक्षण एक बहुत उबाऊ मामला है। उन्हें समझना आम तौर पर अंधेरा है। यही है, आप इसे समझ सकते हैं, लेकिन इसके लिए गंभीर समय और प्रेरणा की आवश्यकता होती है। कार्यान्वयन की शुरुआत में, लोगों को एक ब्याज और प्रेरणा थी कि वे यह पता लगाने के लिए सब कुछ ठीक करें कि यह इकाई परीक्षण और टीडीडी क्या है। लेकिन बहुत जल्द ही यह पारित हो गया।
इस प्रकार, प्रोग्रामर को नियंत्रित करना मुश्किल है कि उसने यूनिट परीक्षणों को अच्छी तरह से लिखा है।
जैसे ही नियंत्रण और प्रशासनिक दबाव कम हो जाता है, प्रोग्रामर, आलसी, यूनिट टेस्ट अधिक से अधिक "शो के लिए" लिखते हैं और मैनुअल या कार्यात्मक परीक्षण का उपयोग करके अपने कोड का परीक्षण करते हैं।
बहुत अधिक त्रुटि लागत वाली प्रणालियों के लिए, प्रोग्रामर यूनिट परीक्षणों के उचित उपयोग के लिए पागल होने के लिए पर्याप्त दबाव महसूस नहीं करते हैं।
यदि प्रोग्रामर कोड में कुछ याद करता है, तो वे इसे क्यूए में या पहले से ही ग्राहक को पकड़ते हैं और सुधार के लिए बग वापस कर देते हैं। प्रतिक्रिया आपको कोड को गंभीरता से और सावधानी से लेती है।
यदि कोई प्रोग्रामर लिखित परीक्षा में कुछ याद करता है, तो कोई भी कभी भी इसे नोटिस नहीं करेगा। प्रतिक्रिया की कमी हमें इस मुद्दे से लापरवाही से संबंधित होने की अनुमति देती है।
यहां तक कि अगर प्रोग्रामर को विकसित करने के लिए पांच गुना अधिक समय मिला है, तो
मैं सावधानीपूर्वक परीक्षण, मोकी, परीक्षण, मोकी ... और इतने दिनों की अवधि के बजाय हबराब्रिज में
जाने और पढ़ने की संभावना रखता हूं।
आप इकाई परीक्षण को "काम" कैसे बना सकते हैं? उन्हें काम करना चाहिए अगर परीक्षण
किसी अन्य प्रोग्रामर द्वारा लिखे गए हैं, और सभी के सर्वश्रेष्ठ कोड खुद
तक ।
और फिर हम टीडीडी में आते हैं।
परीक्षण संचालित विकास
यदि परीक्षण को प्रोग्रामर को इनपुट के रूप में पहले और प्रदान किया गया है, तो यह "तकनीकी आवश्यकता" बन जाता है। बेशक, जो परीक्षण लिखता है उसे अग्रिम में सभी आवश्यक mokeys लिखना और प्रोग्राम करना होगा। हाहा, मैं ऐसा प्रोग्रामर नहीं बनना चाहूंगा जिसका काम दूसरों के लिए टेस्ट करना हो।
अच्छा, क्या कोई प्रोग्रामर स्वयं अपने कोड के लिए पहले से परीक्षण लिख सकता है?
मेरे अनुभव में, नहीं और नहीं। प्रोग्रामर (और मैं और विशाल बहुमत जिसके साथ मैंने इस पर चर्चा की) बस विपरीत दिशा में सोचते हैं।
हां, पहले तो लोगों ने कार्यप्रणाली का ईमानदारी से पालन करने की कोशिश की। लेकिन कुछ समय बाद, उन्होंने पहले कोड लिखना शुरू किया, और फिर उसमें परीक्षण जोड़े। और कुछ समय बाद, परीक्षणों ने अपनी बहुमुखी प्रतिभा और सावधानी खो दी। और तब "shtob" लिखा गया था, जब से वे पूछते हैं।
लेकिन क्या यह जरूरी भी है?