सामने का परीक्षण

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

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

परीक्षण के सिद्धांत

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

यहां चार सिद्धांत दिए गए हैं।

▍ सिद्धांत संख्या १। टेस्ट को अनुकूलन कार्यों के रूप में समझा जाना चाहिए

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

• क्या संभावना है कि इस परीक्षण में त्रुटि मिलेगी?
• क्या यह परीक्षण हमारे परीक्षण प्रणाली में सुधार करता है और क्या इसे लिखने के लिए आवश्यक संसाधनों की लागत है जो इससे प्राप्त लाभ के लायक है?
• क्या यह संभव है कि परीक्षण किए जा रहे निकाय में समान स्तर का विश्वास प्राप्त किया जा सके, जो यह परीक्षण एक और परीक्षण बनाकर देता है जो लिखना, बनाए रखना और चलाना आसान होता है?

2 सिद्धांत संख्या २। मोक्स की अधिकता से बचा जाना चाहिए।

"मोक" की अवधारणा की मेरी पसंदीदा व्याख्याओं में से एक Assert.js 2018 सम्मेलन से इस प्रस्तुति में दी गई थी। स्पीकर ने प्रश्न को अधिक गहराई से खोला जितना मैं इसे यहां खोलने जा रहा हूं। भाषण में, मोक्स के निर्माण की तुलना "वास्तविकता में छिद्रण छेद" से की जाती है। और मुझे लगता है कि यह मोक्ष मानने का एक बहुत ही दृश्य तरीका है। यद्यपि हमारे परीक्षणों में मोक होते हैं, हम उन परीक्षणों की "लागत" में कमी की तुलना करते हैं जो मोक लेखन और चलाने की प्रक्रिया को सरल बनाने के द्वारा प्रदान करते हैं, परीक्षणों के मूल्य में कमी के साथ जो वास्तविकता में एक और छेद का कारण बनता है।

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

it('renders ', () => {   const wrapper = shallow();   //  ,              expect(wrapper).toMatchSnapshot(); }); 

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

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

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

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

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

4 सिद्धांत संख्या ४। टेस्ट को पुन: पेश करना चाहिए कि वास्तविक उपयोगकर्ता एप्लिकेशन के साथ कैसे काम करते हैं

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

परीक्षण उपकरण

अब जब हमने उन लक्ष्यों को परिभाषित कर लिया है जिन्हें हम प्राप्त करना चाहते हैं, तो आइए इस बारे में बात करते हैं कि हमने इसके लिए कौन से उपकरण चुने हैं।

▍TypeScript

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

▍जस्ट (इकाई परीक्षण)

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

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

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

परीक्षण उपकरण

▍पार्टी (एकीकरण परीक्षण)

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

किसी एप्लिकेशन की नेटवर्क लेयर को अनुकरण करने के लिए मोक्स का उपयोग करने की कई ताकतें हैं:

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

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

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

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

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

)पार्टी (एंड-टू-एंड टेस्टिंग)

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

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

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

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

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

हमारे व्यापक परीक्षण रणनीति के विपक्ष

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

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

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

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

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

परिणाम

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

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

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

प्रिय पाठकों! फ्रंटएंड टेस्टिंग में आप किन रणनीतियों का पालन करते हैं? आप कौन से फ्रंटएंड टेस्टिंग टूल का उपयोग करते हैं?