यूनिट परीक्षण क्या है? [बन्द है]


211

मैंने विशिष्ट भाषा में यूनिट टेस्ट के लिए 'कैसे' से कई सवाल पूछे, लेकिन 'क्या', 'क्यों', और 'कब' से कोई प्रश्न नहीं देखा।

  • यह क्या है?
  • यह मेरे लिए क्या करता है?
  • मुझे क्यों इसका उपयोग करना चाहिए?
  • मुझे इसका उपयोग कब करना चाहिए (जब नहीं भी)?
  • कुछ सामान्य नुकसान और गलतफहमी क्या हैं

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

स्वच्छ कोड वार्ता: youtube.com/watch?v=wEhu57pih5w
किरन

1
यह 1 विशिष्ट प्रश्न नहीं है। यह 5 व्यापक प्रश्न हैं।
राडवल्ड

9
अच्छी बात है कि आपने यह सवाल पूछा, एक ऑनलाइन प्रोग्राम को पढ़ने की तुलना में एक कामकाजी प्रोग्रामर का उत्तर पढ़ना ज्यादा बेहतर है और इस बिंदु पर है।
प्रत्यूष धानुका

जवाबों:


197

यूनिट परीक्षण, मोटे तौर पर बोल रहा है, परीक्षण कोड के साथ अलगाव में अपने कोड के परीक्षण बिट्स। दिमाग में आने वाले तात्कालिक फायदे हैं:

  • परीक्षण चलाना स्वचालित-सक्षम और दोहराए जाने योग्य हो जाता है
  • आप GUI के माध्यम से बिंदु-और-क्लिक परीक्षण की तुलना में बहुत अधिक दानेदार स्तर पर परीक्षण कर सकते हैं

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

इकाई परीक्षण को देखने का एक और तरीका यह है कि आप पहले परीक्षण लिखें। इसे टेस्ट-ड्रिवेन डेवलपमेंट (शॉर्ट के लिए टीडीडी) के रूप में जाना जाता है। TDD अतिरिक्त लाभ लाता है:

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

यदि आप अभी यूनिट परीक्षण नहीं कर रहे हैं, तो मेरा सुझाव है कि आप इस पर आरंभ करें। एक अच्छी पुस्तक प्राप्त करें, व्यावहारिक रूप से कोई भी xUnit- पुस्तक करेगा क्योंकि अवधारणाएं उनके बीच बहुत अधिक हस्तांतरणीय हैं।

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


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


2
क्या आप अपने बिंदु पर विस्तार करेंगे कि टीडीडी विकास की गति कैसे बढ़ाता है?
मार्टिन

70

मैं डैन से असहमत नहीं हूं (हालांकि एक बेहतर विकल्प सिर्फ जवाब देने के लिए नहीं हो सकता है) ... लेकिन ...

यूनिट परीक्षण आपके सिस्टम के व्यवहार और कार्यक्षमता का परीक्षण करने के लिए कोड लिखने की प्रक्रिया है।

स्पष्ट रूप से परीक्षण आपके कोड की गुणवत्ता में सुधार करते हैं, लेकिन यह इकाई परीक्षण का सिर्फ एक सतही लाभ है। वास्तविक लाभ इस प्रकार हैं:

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

आपको इकाई परीक्षण करना चाहिए क्योंकि आपके हित में अपने ग्राहक के लिए एक रखरखाव योग्य और गुणवत्ता वाले उत्पाद देने के लिए।

मेरा सुझाव है कि आप इसे किसी भी सिस्टम, या सिस्टम के एक भाग के लिए उपयोग करें, जो वास्तविक दुनिया के व्यवहार को दर्शाता है। दूसरे शब्दों में, यह उद्यम विकास के लिए विशेष रूप से अनुकूल है। मैं इसे दूर-फेंक / उपयोगिता कार्यक्रमों के लिए उपयोग नहीं करूंगा। मैं इसका उपयोग ऐसे सिस्टम के कुछ हिस्सों के लिए नहीं करूँगा जो परीक्षण के लिए समस्याग्रस्त हैं (UI एक सामान्य उदाहरण है, लेकिन यह हमेशा ऐसा नहीं होता है)

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

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


44

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

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

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

यह हाथ परीक्षण पर इकाई परीक्षणों का मुख्य लाभ है। लेकिन रुकिए, और भी है:

  • इकाई परीक्षण नाटकीय रूप से विकास की प्रतिक्रिया को छोटा करता है: एक अलग परीक्षण विभाग के साथ आपको यह जानने में सप्ताह लग सकते हैं कि आपके कोड में एक बग है, जिस समय तक आप पहले से ही संदर्भ के बहुत कुछ भूल चुके हैं, इस प्रकार आपको घंटों लग सकते हैं बग को ढूंढें और ठीक करें; यूनिट परीक्षणों के साथ OTOH, प्रतिक्रिया चक्र को सेकंड में मापा जाता है, और बग फिक्स प्रक्रिया आमतौर पर "ओह श * टी" की तर्ज पर होती है, मैं यहां उस स्थिति की जांच करना भूल गया ":-)
  • इकाई आपके कोड के व्यवहार को प्रभावी ढंग से दस्तावेज (आपकी समझ) का परीक्षण करती है
  • इकाई परीक्षण आपको अपने डिजाइन विकल्पों का पुनर्मूल्यांकन करने के लिए मजबूर करता है, जिसके परिणामस्वरूप सरल, क्लीनर डिजाइन होता है

यूनिट टेस्टिंग फ्रेमवर्क, बदले में, आपके लिए अपने परीक्षण लिखना और चलाना आसान बनाते हैं।


+1 इसके अलावा, परीक्षण कोड के बारे में मेरा पसंदीदा हिस्सा (विशेषकर जब एक नया कोडबेस दिया गया है): यह परीक्षण के तहत कोड के अपेक्षित उपयोग को प्रदर्शित करता है।
स्टीवन एवर्स

34

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

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

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

समाधान इकाई परीक्षण है। जब आप कोड लिखते हैं तो वे समस्याएँ पकड़ लेंगे - जो कि ठीक है - लेकिन आप ऐसा कर सकते हैं। असली अदायगी यह है कि जब आप अब पूरी तरह से अलग परियोजना पर काम कर रहे हैं, तो वे नौ महीने लाइन में समस्याएँ झेलेंगे, लेकिन एक समर इंटर्न को लगता है कि अगर यह पैरामीटर वर्णमाला के क्रम में थे, तो यह और अधिक स्पष्ट होगा - और फिर यूनिट टेस्ट आपने लिखा था कि वापस आने में विफल रहता है, और जब तक वह पैरामीटर ऑर्डर वापस नहीं लेता है तब तक कोई व्यक्ति इंटर्न पर चीजें फेंकता है। यह इकाई परीक्षणों का "क्यों" है। :-)


13

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

  1. TDD का मतलब कोड की मात्रा से दोगुना लिखना नहीं है। टेस्ट कोड आमतौर पर लिखने में काफी तेज और दर्द रहित होता है और यह आपकी डिजाइन प्रक्रिया का महत्वपूर्ण हिस्सा है और गंभीर रूप से महत्वपूर्ण है।

  2. TDD कोडिंग को रोकने के लिए आपको एहसास करने में मदद करता है! आपके परीक्षण आपको विश्वास दिलाते हैं कि आपने अभी के लिए काफी कुछ किया है और ट्विकिंग को रोक सकते हैं और अगली बात पर आगे बढ़ सकते हैं।

  3. परीक्षण और कोड बेहतर कोड प्राप्त करने के लिए एक साथ काम करते हैं। आपका कोड खराब / छोटी हो सकता है। आपका परीक्षण खराब / छोटी गाड़ी हो सकता है। TDD में आप BOTH खराब होने की संभावना पर बैंकिंग कर रहे हैं / छोटी गाड़ी काफी कम है। अक्सर इसका परीक्षण जिसे फिक्सिंग की आवश्यकता होती है, लेकिन यह अभी भी एक अच्छा परिणाम है।

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

  5. एक समान नस में, ये डिज़ाइनर प्रकार देख सकते हैं कि वे क्या काम कर रहे हैं। वे एक रस / सिगरेट / आईफोन को तोड़ने के लिए भटक सकते हैं और एक मॉनिटर पर लौट सकते हैं जो तुरंत उन्हें एक दृश्य क्यू देता है जहां वह गया है। टीडीडी हमें कुछ ऐसा ही देता है। यह देखना आसान है कि हमें जीवन में हस्तक्षेप करने के लिए कहां मिला ...

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

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

यह प्रस्तुति सभी स्वादिष्ट अच्छाई के परीक्षण के लिए एक उत्कृष्ट परिचय है।


7

मैं जेरार्ड मेस्जारोस द्वारा xUnit परीक्षण पैटर्न पुस्तक की सिफारिश करना चाहूंगा। यह बड़ा है, लेकिन यूनिट परीक्षण पर एक महान संसाधन है। यहां उसकी वेब साइट का लिंक दिया गया है जहां वह यूनिट टेस्टिंग की मूल बातें पर चर्चा करता है। http://xunitpatterns.com/XUnitBasics.html


5

समय बचाने के लिए मैं यूनिट परीक्षणों का उपयोग करता हूं।

व्यावसायिक तर्क (या डेटा एक्सेस) का निर्माण करते समय परीक्षण कार्यक्षमता में अक्सर बहुत सारे स्क्रीन में टाइपिंग सामान शामिल हो सकते हैं जो अभी तक समाप्त नहीं हो सकते हैं या नहीं हो सकते हैं। इन परीक्षणों को स्वचालित करने से समय की बचत होती है।

मेरे लिए इकाई परीक्षण एक प्रकार का संशोधित परीक्षण दोहन है। आमतौर पर प्रति सार्वजनिक समारोह में कम से कम एक परीक्षा होती है। मैं विभिन्न व्यवहारों को कवर करने के लिए अतिरिक्त परीक्षण लिखता हूं।

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

मेरे लिए यह पता लगाना बहुत तेज़ है कि मेरा नया कोड मेरे यूनिट परीक्षणों में कुछ तोड़ता है और फिर कोड की जांच करता है और कुछ फ्रंट-एंड डेवलपर को समस्या मिलती है।

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

इकाई परीक्षण सभी परीक्षण आवश्यकताओं को हल करने में सक्षम नहीं होने जा रहे हैं। वे विकास के समय को बचाने और आवेदन के मुख्य भागों का परीक्षण करने में सक्षम होंगे।


4

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

यह सबसे प्रभावी है जब सभी इकाई परीक्षण स्वचालित रूप से चलाए जा सकते हैं।

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

फ्रेमवर्क आपके कोड के खिलाफ सभी परीक्षण चलाएगा और फिर प्रत्येक परीक्षण की सफलता या विफलता की रिपोर्ट करेगा। phpUnit को डिफ़ॉल्ट रूप से लिनक्स कमांड लाइन से चलाया जाता है, हालाँकि इसके लिए HTTP इंटरफेस उपलब्ध हैं। SimpleTest स्वभाव से वेब-आधारित है और आईएमओ उठने और चलने में बहुत आसान है। XDebug के संयोजन में, phpUnit आपको कोड कवरेज के लिए स्वचालित आंकड़े दे सकता है जो कुछ लोगों को बहुत उपयोगी लगते हैं।

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

अपने आवेदन के रूप में उसी रिपॉजिटरी में अपनी यूनिट परीक्षणों को रखने के लिए यह अच्छा अभ्यास है।


4

जैसे पुस्तकालयों NUnit , XUnit या JUnit सिर्फ अनिवार्य आप उपयोग कर अपनी परियोजनाओं को विकसित करना चाहते हैं कर रहे हैं TDD दृष्टिकोण केंट बैक द्वारा लोकप्रिय बनाया:

आप टेस्ट ड्रिवेन डेवलपमेंट (TDD) या केंट बेक की पुस्तक टेस्ट ड्रिवेन डेवलपमेंट: बाय उदाहरण के लिए परिचय पढ़ सकते हैं

फिर, अगर आप होना चाहते हैं सुनिश्चित करें कि आपके परीक्षण अपने कोड की एक "अच्छा" हिस्से को कवर, आप की तरह सॉफ्टवेयर का उपयोग कर सकते Ncover , JCover , PartCover या जो कुछ भी। वे आपको अपने कोड का कवरेज प्रतिशत बताएंगे। टीडीडी में आप कितना माहिर हैं, इसके आधार पर, आपको पता चल जाएगा कि क्या आपने इसे अच्छी तरह से अभ्यास किया है :)


3

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

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

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

मान लें कि आपके फ़ंक्शन ने डेटाबेस से कुछ संख्याओं को पुनर्प्राप्त किया और फिर एक मानक विचलन गणना की। आप यहाँ क्या परीक्षण करने की कोशिश कर रहे हैं? मानक विचलन की सही गणना की जाती है या डेटा डेटाबेस से वापस किया जाता है?

एक इकाई परीक्षण में आप बस यह परीक्षण करना चाहते हैं कि मानक विचलन की सही गणना की जाती है। एक एकीकरण परीक्षण में आप मानक विचलन गणना और डेटाबेस पुनर्प्राप्ति का परीक्षण करना चाहते हैं।


3

यूनिट परीक्षण लेखन कोड के बारे में है जो आपके एप्लिकेशन कोड का परीक्षण करता है।

यूनिट के नाम का हिस्सा एक बार में इरादा कोड की छोटी इकाइयों का परीक्षण करने (उदाहरण के लिए एक विधि) के बारे में है।

इस परीक्षण में मदद करने के लिए xUnit है - वे चौखटे हैं जो इसके साथ सहायता करते हैं। इसका एक हिस्सा स्वचालित परीक्षण धावक है जो आपको बताता है कि कौन सी परीक्षा विफल है और कौन से पास हैं।

उनके पास कॉमन कोड सेटअप करने की भी सुविधा है जो आपको हाथ में आने से पहले प्रत्येक टेस्ट में चाहिए और जब सभी टेस्ट खत्म हो जाएं तो उसे फाड़ दें।

आपके पास यह जांचने के लिए एक परीक्षण हो सकता है कि एक अपेक्षित अपवाद फेंक दिया गया है, बिना पूरे प्रयास को पकड़ने के लिए अपने आप को ब्लॉक करें।


3

मुझे लगता है कि जो बिंदु आपको समझ में नहीं आ रहा है, वह यह है कि एनयूनिट (और इस तरह) की तरह इकाई परीक्षण रूपरेखा आपको छोटे से मध्यम आकार के परीक्षणों को स्वचालित करने में मदद करेगी । आमतौर पर आप GUI में परीक्षण चला सकते हैं ( उदाहरण के लिए NUnit के मामले में ), बस एक बटन पर क्लिक करके और फिर - उम्मीद है - प्रगति बार को हरा रहें। यदि यह लाल हो जाता है, तो रूपरेखा आपको दिखाती है कि कौन सा परीक्षण विफल हुआ और क्या गलत हुआ। एक सामान्य इकाई परीक्षण में, आप अक्सर अभिकथन का उपयोग करते हैं, उदाहरण के लिए Assert.AreEqual(expectedValue, actualValue, "some description")- इसलिए यदि दो मान असमान हैं, तो आपको "कुछ विवरण: अपेक्षित <अपेक्षितवैलू" कहते हुए एक त्रुटि दिखाई देगी, लेकिन <realValue> "था।

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



3

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

XUnit , NUnit , mbUnit , आदि उपकरण जो परीक्षण लेखन में आपको मदद कर रहे हैं।


2

टेस्ट ड्रिवेन डेवलपमेंट में यूनिट टेस्ट शब्द को लिया गया है। एक पुराने टाइमर के रूप में मैं इसकी अधिक सामान्य परिभाषा का उल्लेख करूंगा।

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

फिर आप सभी घटकों के एक साथ काम करने के परीक्षण द्वारा एकीकृत या सिस्टम परीक्षण के लिए आगे बढ़ेंगे।


2

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


1

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

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

मुझे अंत तक नहीं मिला, क्योंकि मुझे अब रूटीन की जरूरत थी, लेकिन यह एक अच्छा व्यायाम था।


1

यदि आप को बकवास का ढेर दिया जाता है और आप ऐसा महसूस करते हैं कि आप किसी साफ सुथरी स्थिति में फंस गए हैं, तो आप जानते हैं कि किसी भी नई सुविधा या कोड के जुड़ने से करंट सेट टूट सकता है क्योंकि वर्तमान सॉफ्टवेयर एक घर की तरह है पत्ते?

फिर हम यूनिट परीक्षण कैसे कर सकते हैं?

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

अभी हम 40% से अधिक हैं, और हम अधिकतर कम लटकने वाले फलों को लेने में सफल रहे हैं।

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


1

यह उत्तर देता है कि आपको इकाई परीक्षण क्यों करना चाहिए।


जावास्क्रिप्ट में कवर यूनिट परीक्षण के नीचे 3 वीडियो, लेकिन सामान्य सिद्धांत अधिकांश भाषाओं में लागू होते हैं।

इकाई परीक्षण: मिनट अब समय बचाएंगे - एरिक मान - https://www.youtube.com/watch?v=_UmmaPeBBcc

जेएस यूनिट परीक्षण (बहुत अच्छा) - https://www.youtube.com/watch?v=-IYqgx8JxlU

टेस्टेबल जावास्क्रिप्ट लिखना - https://www.youtube.com/watch?v=OzjogCFO4Zo


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

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


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

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


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

इसके अलावा, यदि आप नहीं चाहते हैं, तो आपको अपने कोड का परीक्षण करने की आवश्यकता नहीं है, लेकिन यह बंद हो जाता है क्योंकि आपकी परियोजना / कोड आधार बड़ा होने लगता है क्योंकि बग को शुरू करने की संभावना बढ़ जाती है।


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.