मैं टेस्ट लिखना चाहता हूं

मैं हमेशा ब्याज के साथ कोड परीक्षण के बारे में लेख पढ़ता हूं। और मैं वास्तव में अपनी परियोजनाओं में परीक्षणों का उपयोग करना चाहता हूं।
लेकिन मैं नहीं कर सकता मुझे अपने लिए प्रोत्साहन नहीं मिल रहा है।

हां, उदाहरणों से परीक्षण लगभग तुरंत लिखे जाते हैं। लेकिन क्या किसी फंक्शन के लिए टेस्ट लिखना जरूरी है

def get_word(): return 'word' 

सवाल बल्कि जटिल है। इसे लिखने से कोई समस्या नहीं होगी, लेकिन यह मूर्त नहीं होगी।
+1 पूर्ण परीक्षण की खुशी के लिए ऐसा परीक्षण लिखने के लिए? मैं बात नहीं देखता।
टेस्ट कवरेज बढ़ाने के लिए? मैं बात नहीं देखता।
बस ऐसे ही? ...

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

लेकिन प्रत्येक फ़ंक्शन के लिए छोटे परीक्षण लिखने का कोई मतलब नहीं है। वे इतना अच्छा काम करते हैं।

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

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

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

हां, एक और महत्वपूर्ण कारक है: ग्राहक समझ नहीं पाएंगे।

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

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

बेशक, मुझे आशा है कि यह केवल हमारे क्षेत्र पर लागू होता है - वेब प्रोग्रामिंग। धन-संबंधी प्रणालियों के लिए, वे प्रणालियाँ जिन पर लोगों का जीवन निर्भर है, आदि। परीक्षणों की आवश्यकता होती है, और वहां ग्राहक समझेंगे कि उनकी आवश्यकता है। मुझे उस पर विश्वास है।