विभिन्न परीक्षण महत्वपूर्ण हैं, जबकि अन्य की आवश्यकता नहीं है।

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

मैंने प्रतिद्वंद्वी को कौशल से नहीं, बल्कि संख्या के आधार पर लेने का फैसला किया और इसलिए यहां आपके पास 19 कारण हैं कि परीक्षण लिखना अभी भी इसके लायक है (कालानुक्रमिक क्रम में)। तो परीक्षण करता है

1. वे बनाए गए वर्ग के एपीआई को विकसित करने में मदद करते हैं। एक वर्ग के इंटरफ़ेस का आविष्कार करने के बजाय, आप इसे टेस्ट लिखने की प्रक्रिया में विकसित करते हैं।
2. एप्लिकेशन आर्किटेक्चर विकसित करने में मदद करें। कम से कम, यह निम्न-स्तरीय वास्तुकला है - एक ऐसा तरीका जो कक्षाएं एक-दूसरे के साथ बातचीत करती हैं। जैसा कि अनुभव से पता चलता है, इस तरह की वास्तुकला, एक नियम के रूप में, सबसे अधिक लचीली और किफायती है।
3. जांचें कि क्या कोई विशिष्ट कोड अभी काम कर रहा है।
4. जांचें कि क्या परिवर्तन किए जाने के बाद कोड का एक निश्चित टुकड़ा काम करेगा।
5. व्यक्तिगत कक्षाओं की कार्यक्षमता का दस्तावेज।
6. सिस्टम के व्यवहार का दस्तावेज़ (उपयोगकर्ता के दृष्टिकोण से)।
7. मैं अभी तक नहीं आया, शायद कोई मुझे बताएगा?

यह स्पष्ट है कि परीक्षण के लिए परीक्षण अलग है, और सभी परीक्षण ऐसे महान लाभ नहीं ला सकते हैं। आइए इसे जानने की कोशिश करें।

क्या हम कोड से पहले या बाद में परीक्षण लिखते हैं?

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

दूसरा महत्वपूर्ण बिंदु: जैसा कि अनुभवी लोग कहते हैं, परीक्षण जो बाद में स्थगित हो जाते हैं, ज्यादातर मामलों में, अलिखित रहते हैं।

निर्णय: हम केवल उन मामलों में कोड के बाद परीक्षण लिखते हैं जब हमें परिणामों के बारे में चिंता किए बिना, जल्दी से पैसा काटने की आवश्यकता होती है।

परीक्षण करने के लिए कोड का कौन सा टुकड़ा?

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

अब देखते हैं कि इस तरह के परीक्षण हमारी अच्छी चीजों की सूची से कैसे संबंधित हैं:

इकाई परीक्षण:

1. वे बनाए गए वर्ग के एपीआई को विकसित करने में मदद करते हैं।
2. एप्लिकेशन आर्किटेक्चर विकसित करने में मदद करें।
3. जांचें कि क्या कोई विशिष्ट कोड अभी काम कर रहा है।
4. जांचें कि क्या परिवर्तन किए जाने के बाद कोड का एक निश्चित टुकड़ा काम करेगा।
5. व्यक्तिगत कक्षाओं की कार्यक्षमता का दस्तावेज।

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

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

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

हमें सामान्य रूप से क्या परीक्षण करना चाहिए?

अधिकांश डेवलपर्स इस सवाल का स्पष्ट और स्पष्ट रूप से, बहुत स्पष्ट, सरल-दिमाग वाला जवाब देंगे: हम कक्षाओं और उनके तरीकों का परीक्षण करेंगे। जल्दी से नहीं कहा। प्रत्येक श्रेणी के लिए जिसे हमारे सरल चंपक ने आविष्कार किया, हम एक परीक्षण वर्ग शुरू करते हैं। उदाहरण के लिए, यदि हमारे पास MyClass है, तो हम आसानी से MyClassTester क्लास बनाते हैं। इसके अलावा, जब से हम पहले से ही यह सुनिश्चित करने के लिए जानते हैं कि हमारे पास DoSomething विधि है, हम TestDoSomething विधि शुरू करते हैं। और, सबसे दिलचस्प बात यह है कि हम रात में उसके बाद शांति से सोते हैं।

वे कहते हैं कि विजुअल स्टूडियो में एक टीम भी है जो स्वचालित रूप से इस पूरी चीज़ को उत्पन्न करती है।

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

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

तो, विकास परीक्षण:

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

उपयोगकर्ता परीक्षण:

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

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

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

अंतिम विचार

मैं कभी भी कुछ फाइनल नहीं कर पाया, इसलिए मैं सब कुछ छोड़ देता हूं।