इकाई परीक्षण: Difference between revisions

Revision as of 15:48, 11 March 2023

कंप्यूटर प्रोग्रामिंग में, इकाई परीक्षण एक सॉफ्टवेयर परीक्षण विधि है जिसके द्वारा स्रोत कोड की भिन्न -भिन्न इकाइयां या कंप्यूटर प्रोग्राम मॉड्यूलर प्रोग्रामिंग के साथ-सापेक्षसंबंधित नियंत्रण डेटा, उपयोग प्रक्रिया , और संचालन प्रक्रियाओं का परीक्षण किया जाता है - यह निर्धारित करने के लिए परीक्षण किया जाता है कि क्या वे उपयोग के योग्य हैं।^[1]

इतिहास

इकाई टेस्टिंग से पहले कैप्चर और रीप्ले परीक्षण टूल आदर्श थे। 1997 में, केंट बेक और एरिक गामा ने JUnit को विकसित और प्रारंभ किया, एक इकाई टेस्ट फ्रेमवर्क जो जावा डेवलपर्स के सापेक्षलोकप्रिय हुआ।^[2] Google ने 2005-2006 के आसपास स्वचालित परीक्षण को अपनाया।^[3]

विवरण

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

उत्पन्न होने वाली समस्याओं को अलग करने के लिए, प्रत्येक परीक्षण घटना का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। मेथड स्टब्स,, मॉक ऑब्जेक्ट्स,फेक और टेस्ट हार्नेस जैसे सब्स्टीट्यूट्स का उपयोग अलगाव में मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।।

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

पैरामीटरयुक्त परीक्षण का उपयोग करके इकाई परीक्षणों को लिखना और बनाए रखना तेजी से बनाया जा सकता है। ये विभिन्न इनपुट सेटों के सापेक्ष एक परीक्षण को कई बार निष्पादित करने की अनुमति देते हैं, इस प्रकार परीक्षण कोड दोहराव को न्यूनतम करते हैं। पारंपरिक इकाई परीक्षणों के विपरीत, जो आमतौर पर बंद विधि हैं और अपरिवर्तनीय स्थितियों का परीक्षण करते हैं, पैरामीटरयुक्त परीक्षण पैरामीटर के किसी भी सेट को लेते हैं। Parameterized परीक्षण TestNG, JUnit और इसके .Net समकक्ष, XUnit द्वारा समर्थित हैं। इकाई परीक्षणों के लिए उपयुक्त पैरामीटर मैन्युअल रूप से आपूर्ति किए जा सकते हैं या कुछ घटनाओं में स्वचालित रूप से परीक्षण ढांचे द्वारा उत्पन्न होते हैं। हाल के वर्षों में अधिक शक्तिशाली (इकाई) परीक्षण लिखने, सिद्धांतों की अवधारणा का लाभ उठाने, समान चरणों को निष्पादित करने वाले परीक्षण मामलों के लिए समर्थन जोड़ा गया था, परंतु रनटाइम पर उत्पन्न परीक्षण डेटा का उपयोग करते हुए, नियमित पैरामीटरयुक्त परीक्षणों के विपरीत, जो इनपुट सेट के सापेक्ष समान निष्पादन चरणों का उपयोग करते हैं जो पूर्व निर्धारित हैं।^[6]^[7]^[8]

लाभ

इकाई परीक्षण का लक्ष्य कार्यक्रम के प्रत्येक भाग को अलग करना है और यह दिखाना है कि भिन्न -भिन्न भाग सही हैं।^[1]एक इकाई परीक्षण अनुबंध द्वारा एक सख्त, लिखित डिज़ाइन प्रदान करता है जो कोड के टुकड़े को संतुष्ट करना चाहिए। नतीजतन, यह कई लाभ प्रदान करता है।

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

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

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

इकाई परीक्षण स्वयं इकाइयों में अनिश्चितता को कम कर सकता है और इसका उपयोग टॉप-डाउन और बॉटम-अप डिज़ाइन | बॉटम-अप परीक्षण शैली दृष्टिकोण में किया जा सकता है। किसी प्रोग्राम के भागों का पहले परीक्षण करके और फिर उसके भागों के योग का परीक्षण करके, एकीकरण परीक्षण बहुत आसान हो जाता है।^{[citation needed]}

इकाई परीक्षण प्रणाली का एक प्रकार का जीवित दस्तावेज प्रदान करता है। इकाई द्वारा कौन सी कार्यक्षमता प्रदान की जाती है, और इसका उपयोग कैसे करना है, यह जानने के इच्छुक डेवलपर्स इकाई के इंटरफ़ेस (अप्लिकेशन प्रोग्रामिंग अंतरफलक) की बुनियादी समझ हासिल करने के लिए इकाई परीक्षण देख सकते हैं।^{[citation needed]}

इकाई परीक्षण के मामले उन विशेषताओं को सम्मिलितकरते हैं जो इकाई की सफलता के लिए महत्वपूर्ण हैं। ये विशेषताएँ एक इकाई के उचित/अनुचित उपयोग के साथ-सापेक्षनकारात्मक व्यवहारों को इंगित कर सकती हैं जिन्हें इकाई द्वारा फंसाया जाना है। एक इकाई परीक्षण मामला, अपने आप में, इन महत्वपूर्ण विशेषताओं को प्रलेखित करता है, हालांकि कई सॉफ्टवेयर विकास वातावरण विकास में उत्पाद को प्रलेखित करने के लिए केवल कोड पर निर्भर नहीं होते हैं।^{[citation needed]}

जब परीक्षण-संचालित दृष्टिकोण का उपयोग करके सॉफ़्टवेयर विकसित किया जाता है, तो इंटरफ़ेस निर्दिष्ट करने के लिए इकाई टेस्ट लिखने का संयोजन और परीक्षण पारित होने के बाद की गई रीफैक्टरिंग गतिविधियां औपचारिक डिजाइन की जगह ले सकती हैं। प्रत्येक इकाई परीक्षण को कक्षाओं, विधियों और अवलोकनीय व्यवहार को निर्दिष्ट करने वाले एक डिजाइन तत्व के रूप में देखा जा सकता है।^{[citation needed]}

सीमाएं और नुकसान

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

इकाई परीक्षणों का एक विस्तृत पदानुक्रम एकीकरण परीक्षण के बराबर नहीं है। परिधीय इकाइयों के सापेक्षएकीकरण को एकीकरण परीक्षणों में सम्मिलितकिया जाना चाहिए, परंतु इकाई परीक्षणों में नहीं।^{[citation needed]} एकीकरण परीक्षण आमतौर पर अभी भी मानव के मैनुअल परीक्षण पर बहुत अधिक निर्भर करता है; उच्च-स्तरीय या वैश्विक-दायरे के परीक्षण को स्वचालित करना मुश्किल हो सकता है, जैसे मैन्युअल परीक्षण प्रायः तेज़ और सस्ता दिखाई देता है।^{[citation needed]}

सॉफ्टवेयर परीक्षण एक मिश्रित समस्या है। उदाहरण के लिए, प्रत्येक बूलियन निर्णय कथन के लिए कम से कम दो परीक्षणों की आवश्यकता होती है: एक सत्य के परिणाम के सापेक्षऔर एक गलत के परिणाम के साथ। परिणामस्वरूप, लिखे गए कोड की प्रत्येक पंक्ति के लिए, प्रोग्रामर को प्रायः टेस्ट कोड की 3 से 5 पंक्तियों की आवश्यकता होती है।^[12] इसमें स्पष्ट रूप से समय लगता है और इसका निवेश प्रयास के लायक नहीं हो सकता है। ऐसी समस्याएं हैं जिनका आसानी से बिल्कुल भी परीक्षण नहीं किया जा सकता है - उदाहरण के लिए वे जो गैर नियतात्मक एल्गोरिथम हैं या जिसमें कई थ्रेड (कंप्यूटर साइंस) सम्मिलितहैं। इसके अलावा, इकाई परीक्षण के लिए कोड उतना ही छोटा होने की संभावना है जितना कोड परीक्षण कर रहा है। द मिथिकल मैन-मंथ में फ्रेड ब्रूक्स उद्धरण: कभी भी दो क्रोनोमीटर के सापेक्षसमुद्र में न जाएं; एक या तीन लो।^[13] मतलब, अगर दो समुद्री क्रोनोमीटर विरोधाभासी हैं, तो आप कैसे जानेंगे कि कौन सा सही है?

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

यह सुनिश्चित करने के लिए एक स्थायी प्रक्रिया को लागू करना भी आवश्यक है कि परीक्षण मामले की विफलताओं की नियमित रूप से समीक्षा की जाती है और तुरंत संबोधित किया जाता है।^[15] यदि इस तरह की प्रक्रिया को लागू नहीं किया जाता है और टीम के वर्कफ़्लो में सम्मिलितहो जाता है, तो एप्लिकेशन इकाई टेस्ट सूट के सापेक्षसिंक से बाहर हो जाएगा, झूठी सकारात्मकता बढ़ जाएगी और टेस्ट सूट की प्रभावशीलता कम हो जाएगी।

इकाई परीक्षण एम्बेडेड सिस्टम सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक अलग प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्षसंभव है।^[16] इकाई परीक्षण सबसे आसान होते हैं जब किसी विधि में इनपुट पैरामीटर और कुछ आउटपुट होते हैं। इकाई परीक्षण बनाना उतना आसान नहीं है जब विधि का एक प्रमुख कार्य अनुप्रयोग के लिए किसी बाहरी चीज़ के सापेक्षसहभागिता करना हो। उदाहरण के लिए, एक विधि जो डेटाबेस के सापेक्षकाम करेगी, उसे बनाने के लिए डेटाबेस इंटरैक्शन के मॉक अप की आवश्यकता हो सकती है, जो संभवतः वास्तविक डेटाबेस इंटरैक्शन के रूप में व्यापक नहीं होगा।^[17]^{[better source needed]}

उदाहरण

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

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class TestAdder {

    // can it add the positive numbers 1 and 1?
    @Test
    public void testSumPositiveNumbersOneAndOne() {
        Adder adder = new AdderImpl();
        assertEquals(2, adder.add(1, 1));
    }

    // can it add the positive numbers 1 and 2?
    @Test
    public void testSumPositiveNumbersOneAndTwo() {
        Adder adder = new AdderImpl();
        assertEquals(3, adder.add(1, 2));
    }

    // can it add the positive numbers 2 and 2?
    @Test
    public void testSumPositiveNumbersTwoAndTwo() {
        Adder adder = new AdderImpl();
        assertEquals(4, adder.add(2, 2));
    }

    // is zero neutral?
    @Test
    public void testSumZeroNeutral() {
        Adder adder = new AdderImpl();
        assertEquals(0, adder.add(0, 0));
    }

    // can it add the negative numbers -1 and -2?
    @Test
    public void testSumNegativeNumbers() {
        Adder adder = new AdderImpl();
        assertEquals(-3, adder.add(-1, -2));
    }

    // can it add a positive and a negative?
    @Test
    public void testSumPositiveAndNegative() {
        Adder adder = new AdderImpl();
        assertEquals(0, adder.add(-1, 1));
    }

    // how about larger numbers?
    @Test
    public void testSumLargeNumbers() {
        Adder adder = new AdderImpl();
        assertEquals(2222, adder.add(1234, 988));
    }
}

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

interface Adder {
    int add(int a, int b);
}
class AdderImpl implements Adder {
    public int add(int a, int b) {
        return a + b;
    }
}

निष्पादन योग्य विनिर्देशों के रूप में

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

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

अनुप्रयोग

चरम प्रोग्रामिंग

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

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

सिस्टम में अधिकांश कोड इकाई टेस्टेड होते हैं, परंतु जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, परंतु यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।^{[citation needed]} एक्सट्रीम प्रोग्रामिंग केवल यह पहचानती है कि परीक्षण शायद ही कभी संपूर्ण होता है (क्योंकि यह आर्थिक रूप से व्यवहार्य होने के लिए प्रायः बहुत महंगा और समय लेने वाला होता है) और सीमित संसाधनों को प्रभावी ढंग से केंद्रित करने के तरीके पर मार्गदर्शन प्रदान करता है।

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

इमर्जेंट डिज़ाइन की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि आकस्मिक डिजाइन रिफैक्टरिंग पर बहुत अधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।^[18]

इकाई टेस्टिंग फ्रेमवर्क

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

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

भाषा-स्तरीय इकाई परीक्षण समर्थन

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

अंतर्निहित इकाई परीक्षण समर्थन वाली भाषाओं में सम्मिलित हैं:

मानक इकाई परीक्षण ढांचे के समर्थन वाली भाषाओं में सम्मिलित हैं:

रेफरी>"न्यूनतम (रूबी 2.0)". Ruby-Doc.org.</ref>

कुछ भाषाओं में बिल्ट-इन इकाई-टेस्टिंग सपोर्ट नहीं करता है, परंतु इकाई टेस्टिंग लाइब्रेरी या फ्रेमवर्क स्थापित हैं। इन भाषाओं में सम्मिलित हैं:

"पेस्टर फ्रेमवर्क". GitHub. Retrieved 28 January 2016.

R परीक्षण के साथ
स्काला
टीसीएल
विजुअल बेसिक .NET
Xojo के साथ XojoUnit

यह भी देखें

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

संदर्भ

↑ ^1.0 ^1.1 Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0.
↑ Gulati, Shekhar (2017). Java Unit Testing with JUnit 5 : Test Driven Development with JUnit 5. Rahul Sharma. Berkeley, CA: Apress. p. 8. ISBN 978-1-4842-3015-2. OCLC 1012347252.
↑ Winters, Titus (2020). Software engineering at Google : lessons learned from programming over time. Tom Manshreck, Hyrum Wright (1st ed.). Sebastopol, CA. ISBN 978-1-4920-8274-3. OCLC 1144086840.{{cite book}}: CS1 maint: location missing publisher (link)
↑ ^4.0 ^4.1 Hamill, Paul (2004). Unit Test Frameworks: Tools for High-Quality Software Development. O'Reilly Media, Inc. ISBN 9780596552817.
↑ Xie, Tao. "ऑब्जेक्ट-ओरिएंटेड प्रोग्राम्स के डिफरेंशियल यूनिट टेस्टिंग के लिए एक फ्रेमवर्क की ओर" (PDF). Retrieved 2012-07-23.
↑ "Getting Started with xUnit.net (desktop)".
↑ "सिद्धांतों". GitHub.
↑ "पैरामीटरयुक्त परीक्षण". GitHub.
↑ Boehm, Barry W.; Papaccio, Philip N. (October 1988). "सॉफ्टवेयर लागत को समझना और नियंत्रित करना" (PDF). IEEE Transactions on Software Engineering. 14 (10): 1462–1477. doi:10.1109/32.6191. Retrieved 13 May 2016.
↑ "जल्दी और अक्सर परीक्षण करें". Microsoft.
↑ "Prove It Works: Using the Unit Test Framework for Software Testing and Validation". National Instruments. 2017-08-21.
↑ Cramblitt, Bob (2007-09-20). "अल्बर्टो सावोइया सॉफ्टवेयर परीक्षण की प्रशंसा करता है". Retrieved 2007-11-29.
↑ Brooks, Frederick J. (1995) [1975]. द मिथिकल मैन-मंथ. Addison-Wesley. p. 64. ISBN 978-0-201-83595-3.
↑ Kolawa, Adam (2009-07-01). "यूनिट परीक्षण सर्वोत्तम अभ्यास". Retrieved 2012-07-23.
↑ daVeiga, Nada (2008-02-06). "Change Code Without Fear: Utilize a regression safety net". Retrieved 2008-02-08.
↑ Kucharski, Marek (2011-11-23). "अंतःस्थापित विकास के लिए इकाई परीक्षण को व्यावहारिक बनाना". Retrieved 2020-07-20.
↑ http://wiki.c2.com/?UnitTestsAndDatabases^{[bare URL]}
↑ "फुर्तीली उभरती डिजाइन". Agile Sherpa. 2010-08-03. Archived from the original on 22 March 2012. Retrieved 2012-05-08.
↑ Bullseye Testing Technology (2006–2008). "मध्यवर्ती कवरेज लक्ष्य". Retrieved 24 March 2009.
↑ "यूनिट टेस्ट - डी प्रोग्रामिंग लैंग्वेज". D Programming Language. D Language Foundation. Retrieved 5 August 2017.
↑ The Rust Project Developers (2011–2014). "The Rust Testing Guide (Rust 0.12.0-pre-nightly)". Retrieved 12 August 2014.
↑ "क्रिस्टल युक्ति". crystal-lang.org. Retrieved 18 September 2017.
↑ "परीक्षण - द गो प्रोग्रामिंग लैंग्वेज". golang.org. Retrieved 3 December 2013.
↑ "Unit Testing · The Julia Language". docs.julialang.org. Retrieved 2022-06-15.
↑ Python Documentation (2016). "यूनिटटेस्ट - यूनिट टेस्टिंग फ्रेमवर्क". Retrieved 18 April 2016.
↑ Welsh, Noel; Culpepper, Ryan. "रैकयूनिट: यूनिट परीक्षण". PLT Design Inc. Retrieved 26 February 2019.
↑ Welsh, Noel; Culpepper, Ryan. "रैकेट यूनिट परीक्षण पैकेज रैकेट मुख्य वितरण का हिस्सा है". PLT Design Inc. Retrieved 26 February 2019.
↑ Sierra, Stuart. "clojure.test के लिए API - क्लोजर v1.6 (स्थिर)". Retrieved 11 February 2015. {{cite web}}: Check date values in: |access-date= (help); line feed character in |access-date= at position 13 (help)

अग्रिम पठन

Feathers, Michael C. (2005). Working Effectively with Legacy Code. Upper Saddle River, NJ: Prentice Hall Professional Technical Reference. ISBN 978-0131177055.

बाहरी संबंध

Test Driven Development (Ward Cunningham's Wiki)

[kolawa-1] 1.0 ^1.1 Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0.

[2] Gulati, Shekhar (2017). Java Unit Testing with JUnit 5 : Test Driven Development with JUnit 5. Rahul Sharma. Berkeley, CA: Apress. p. 8. ISBN 978-1-4842-3015-2. OCLC 1012347252.

[3] Winters, Titus (2020). Software engineering at Google : lessons learned from programming over time. Tom Manshreck, Hyrum Wright (1st ed.). Sebastopol, CA. ISBN 978-1-4920-8274-3. OCLC 1144086840.{{cite book}}: CS1 maint: location missing publisher (link)

[hamill-4] 4.0 ^4.1 Hamill, Paul (2004). Unit Test Frameworks: Tools for High-Quality Software Development. O'Reilly Media, Inc. ISBN 9780596552817.

[5] Xie, Tao. "ऑब्जेक्ट-ओरिएंटेड प्रोग्राम्स के डिफरेंशियल यूनिट टेस्टिंग के लिए एक फ्रेमवर्क की ओर" (PDF). Retrieved 2012-07-23.

[6] "Getting Started with xUnit.net (desktop)".

[7] "सिद्धांतों". GitHub.

[8] "पैरामीटरयुक्त परीक्षण". GitHub.

[9] Boehm, Barry W.; Papaccio, Philip N. (October 1988). "सॉफ्टवेयर लागत को समझना और नियंत्रित करना" (PDF). IEEE Transactions on Software Engineering. 14 (10): 1462–1477. doi:10.1109/32.6191. Retrieved 13 May 2016.

[10] "जल्दी और अक्सर परीक्षण करें". Microsoft.

[11] "Prove It Works: Using the Unit Test Framework for Software Testing and Validation". National Instruments. 2017-08-21.

[12] Cramblitt, Bob (2007-09-20). "अल्बर्टो सावोइया सॉफ्टवेयर परीक्षण की प्रशंसा करता है". Retrieved 2007-11-29.

[13] Brooks, Frederick J. (1995) [1975]. द मिथिकल मैन-मंथ. Addison-Wesley. p. 64. ISBN 978-0-201-83595-3.

[14] Kolawa, Adam (2009-07-01). "यूनिट परीक्षण सर्वोत्तम अभ्यास". Retrieved 2012-07-23.

[15] Veiga, Nada (2008-02-06). "Change Code Without Fear: Utilize a regression safety net". Retrieved 2008-02-08.

[16] Kucharski, Marek (2011-11-23). "अंतःस्थापित विकास के लिए इकाई परीक्षण को व्यावहारिक बनाना". Retrieved 2020-07-20.

[17] ttp://wiki.c2.com/?UnitTestsAndDatabases^{[bare URL]}

[18] "फुर्तीली उभरती डिजाइन". Agile Sherpa. 2010-08-03. Archived from the original on 22 March 2012. Retrieved 2012-05-08.

[19] Bullseye Testing Technology (2006–2008). "मध्यवर्ती कवरेज लक्ष्य". Retrieved 24 March 2009.

[20] "यूनिट टेस्ट - डी प्रोग्रामिंग लैंग्वेज". D Programming Language. D Language Foundation. Retrieved 5 August 2017.

[21] The Rust Project Developers (2011–2014). "The Rust Testing Guide (Rust 0.12.0-pre-nightly)". Retrieved 12 August 2014.

[22] "क्रिस्टल युक्ति". crystal-lang.org. Retrieved 18 September 2017.

[23] "परीक्षण - द गो प्रोग्रामिंग लैंग्वेज". golang.org. Retrieved 3 December 2013.

[24] "Unit Testing · The Julia Language". docs.julialang.org. Retrieved 2022-06-15.

[25] Python Documentation (2016). "यूनिटटेस्ट - यूनिट टेस्टिंग फ्रेमवर्क". Retrieved 18 April 2016.

[Racket_Unit_Testing-26] Welsh, Noel; Culpepper, Ryan. "रैकयूनिट: यूनिट परीक्षण". PLT Design Inc. Retrieved 26 February 2019.

[Racket_Unit_Testing_Main_dist-27] Welsh, Noel; Culpepper, Ryan. "रैकेट यूनिट परीक्षण पैकेज रैकेट मुख्य वितरण का हिस्सा है". PLT Design Inc. Retrieved 26 February 2019.

[Clojure_Unit_Testing_Framework-28] Sierra, Stuart. "clojure.test के लिए API - क्लोजर v1.6 (स्थिर)". Retrieved 11 February 2015. {{cite web}}: Check date values in: |access-date= (help); line feed character in |access-date= at position 13 (help)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

@@ Line 1: / Line 1: @@
 {{short description|Software testing method by which individual units of source code are validated}}
-{{Use dmy dates|date=April 2020}}
 {{Software development process|Core activities}}
-[[कंप्यूटर प्रोग्रामिंग]] में, यूनिट परीक्षण एक सॉफ्टवेयर परीक्षण विधि है जिसके द्वारा स्रोत कोड की अलग-अलग इकाइयां - एक या अधिक कंप्यूटर प्रोग्राम [[मॉड्यूलर प्रोग्रामिंग]] के साथ-साथ संबंधित नियंत्रण डेटा, उपयोग [[प्रक्रिया (कंप्यूटर विज्ञान)]], और संचालन प्रक्रियाओं का परीक्षण किया जाता है - यह निर्धारित करने के लिए परीक्षण किया जाता है कि क्या वे उपयोग के योग्य हैं।<ref name="kolawa">{{cite book | last = Kolawa | first = Adam |author2=Huizinga, Dorota  | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page=75 | isbn = 978-0-470-04212-0 }}</ref>
+[[कंप्यूटर प्रोग्रामिंग]] में, इकाई परीक्षण एक सॉफ्टवेयर परीक्षण विधि है जिसके द्वारा स्रोत कोड की भिन्न -भिन्न  इकाइयां  या कंप्यूटर प्रोग्राम [[मॉड्यूलर प्रोग्रामिंग]] के साथ-सापेक्षसंबंधित नियंत्रण डेटा, उपयोग [[प्रक्रिया (कंप्यूटर विज्ञान)|प्रक्रिया]] , और संचालन प्रक्रियाओं का परीक्षण किया जाता है - यह निर्धारित करने के लिए परीक्षण किया जाता है कि क्या वे उपयोग के योग्य हैं।<ref name="kolawa">{{cite book | last = Kolawa | first = Adam |author2=Huizinga, Dorota  | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page=75 | isbn = 978-0-470-04212-0 }}</ref>
 == इतिहास ==
-{{Expand section|date=June 2022}}
+इकाई टेस्टिंग से पहले  [[कब्जा और फिर से परीक्षण परीक्षण|कैप्चर और रीप्ले परीक्षण]] टूल आदर्श थे। 1997 में, [[केंट बेक]] और [[एरिक गामा]] ने [[JUnit]] को विकसित और प्रारंभ किया, एक इकाई टेस्ट फ्रेमवर्क जो [[ जावा (प्रोग्रामिंग भाषा) | जावा]] डेवलपर्स के सापेक्षलोकप्रिय हुआ।<ref>{{Cite book |last=Gulati |first=Shekhar |url=https://www.worldcat.org/oclc/1012347252 |title=Java Unit Testing with JUnit 5 : Test Driven Development with JUnit 5 |date=2017 |publisher=Apress |others=Rahul Sharma |isbn=978-1-4842-3015-2 |location=Berkeley, CA |pages=8 |oclc=1012347252}}</ref> [[Google]] ने 2005-2006 के आसपास स्वचालित परीक्षण को अपनाया।<ref>{{Cite book |last=Winters |first=Titus |url=https://www.worldcat.org/oclc/1144086840 |title=Software engineering at Google : lessons learned from programming over time |date=2020 |others=Tom Manshreck, Hyrum Wright |isbn=978-1-4920-8274-3 |edition=1st |location=Sebastopol, CA |oclc=1144086840}}</ref>
-यूनिट टेस्टिंग से पहले, [[कब्जा और फिर से परीक्षण परीक्षण]] टूल आदर्श थे। 1997 में, [[केंट बेक]] और [[एरिक गामा]] ने [[JUnit]] को विकसित और जारी किया, एक यूनिट टेस्ट फ्रेमवर्क जो [[ जावा (प्रोग्रामिंग भाषा) ]] डेवलपर्स के साथ लोकप्रिय हुआ।<ref>{{Cite book |last=Gulati |first=Shekhar |url=https://www.worldcat.org/oclc/1012347252 |title=Java Unit Testing with JUnit 5 : Test Driven Development with JUnit 5 |date=2017 |publisher=Apress |others=Rahul Sharma |isbn=978-1-4842-3015-2 |location=Berkeley, CA |pages=8 |oclc=1012347252}}</ref> [[Google]] ने 2005-2006 के आसपास स्वचालित परीक्षण को अपनाया।<ref>{{Cite book |last=Winters |first=Titus |url=https://www.worldcat.org/oclc/1144086840 |title=Software engineering at Google : lessons learned from programming over time |date=2020 |others=Tom Manshreck, Hyrum Wright |isbn=978-1-4920-8274-3 |edition=1st |location=Sebastopol, CA |oclc=1144086840}}</ref>
 == विवरण ==
-{{more citations needed section|date=September 2019}}
-यूनिट परीक्षण आमतौर पर [[सॉफ्टवेयर डेवलपर]] द्वारा लिखित और चलाए जाने वाले [[स्वचालित परीक्षण]] होते हैं ताकि यह सुनिश्चित किया जा सके कि किसी एप्लिकेशन का एक भाग (यूनिट के रूप में जाना जाता है) अपने [[सॉफ्टवेर डिज़ाइन]] को पूरा करता है और इच्छित व्यवहार करता है।<ref name="hamill">{{cite book |last1=Hamill |first1=Paul |title=Unit Test Frameworks: Tools for High-Quality Software Development |date=2004 |publisher=O'Reilly Media, Inc.|isbn=9780596552817 |url=https://books.google.com/books?id=2ksvdhhnWQsC}}</ref> [[प्रक्रियात्मक प्रोग्रामिंग]] में, एक इकाई एक संपूर्ण मॉड्यूल हो सकती है, लेकिन यह आमतौर पर एक व्यक्तिगत कार्य या प्रक्रिया है। वस्तु-उन्मुख प्रोग्रामिंग में, एक इकाई अक्सर एक संपूर्ण इंटरफ़ेस होती है, जैसे कि एक वर्ग या एक व्यक्तिगत विधि।<ref>{{cite web|url=http://people.engr.ncsu.edu/txie/publications/ast07-diffut.pdf|title=ऑब्जेक्ट-ओरिएंटेड प्रोग्राम्स के डिफरेंशियल यूनिट टेस्टिंग के लिए एक फ्रेमवर्क की ओर|last=Xie|first=Tao|author-link=Tao Xie|access-date=2012-07-23}}</ref> सबसे छोटी परीक्षण योग्य इकाइयों के लिए पहले परीक्षण लिखकर, फिर उन दोनों के बीच मिश्रित व्यवहार, जटिल अनुप्रयोगों के लिए व्यापक परीक्षण तैयार कर सकते हैं।<ref name="hamill" />
-उत्पन्न होने वाली समस्याओं को अलग करने के लिए, प्रत्येक परीक्षण मामले का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। [[विधि ठूंठ]], [[ नकली वस्तु ]]्स जैसे स्थानापन्न,<ref name="mocksarentstubs">{{cite web|url=http://martinfowler.com/articles/mocksArentStubs.html|title=मोक स्टब्स नहीं हैं|date=2007-01-02|last=Fowler|first=Martin|author-link=Martin Fowler (software engineer)|access-date=2008-04-01}}</ref> नकली वस्तु#Mocks.2C नकली. 2C और स्टब्स, और परीक्षण हार्नेस का उपयोग अलगाव में एक मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।
-विकास के दौरान, एक सॉफ्टवेयर डेवलपर यूनिट की शुद्धता को सत्यापित करने के लिए परीक्षण में मापदंड, या परिणाम जो अच्छे माने जाते हैं, को कोड कर सकता है। टेस्ट केस एक्जीक्यूशन के दौरान, फ्रेमवर्क [[कंप्यूटर डेटा लॉगिंग]] टेस्ट जो किसी भी मानदंड को विफल करते हैं और उन्हें सारांश में रिपोर्ट करते हैं। इसके लिए, सबसे अधिक इस्तेमाल किया जाने वाला तरीका टेस्ट-फंक्शन-अपेक्षित मूल्य है।
+इकाई परीक्षण आमतौर पर [[सॉफ्टवेयर डेवलपर]] द्वारा लिखित और चलाए जाने वाले [[स्वचालित परीक्षण]] होते हैं यद्यपि यह सुनिश्चित किया जा सके कि किसी एप्लिकेशन का एक भाग (इकाई के रूप में जाना जाता है) अपने [[सॉफ्टवेर डिज़ाइन]] को पूर्ण करता है और इच्छित व्यवहार करता है।<ref name="hamill">{{cite book |last1=Hamill |first1=Paul |title=Unit Test Frameworks: Tools for High-Quality Software Development |date=2004 |publisher=O'Reilly Media, Inc.|isbn=9780596552817 |url=https://books.google.com/books?id=2ksvdhhnWQsC}}</ref> [[प्रक्रियात्मक प्रोग्रामिंग]] में, एक इकाई एक संपूर्ण मॉड्यूल हो सकती है, परंतु यह आमतौर पर एक व्यक्तिगत कार्य या प्रक्रिया है। वस्तु-उन्मुख प्रोग्रामिंग में, एक इकाई  प्रायः एक संपूर्ण इंटरफ़ेस होती है, जैसे कि एक वर्ग या एक व्यक्तिगत विधि।<ref>{{cite web|url=http://people.engr.ncsu.edu/txie/publications/ast07-diffut.pdf|title=ऑब्जेक्ट-ओरिएंटेड प्रोग्राम्स के डिफरेंशियल यूनिट टेस्टिंग के लिए एक फ्रेमवर्क की ओर|last=Xie|first=Tao|author-link=Tao Xie|access-date=2012-07-23}}</ref> सबसे छोटी परीक्षण योग्य इकाइयों के लिए पहले परीक्षण लिखकर, फिर उन दोनों के मध्य मिश्रित व्यवहार, जटिल अनुप्रयोगों के लिए व्यापक परीक्षण तैयार कर सकते हैं।<ref name="hamill" />
+उत्पन्न होने वाली समस्याओं को अलग करने के लिए, प्रत्येक परीक्षण घटना का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। [[विधि ठूंठ|मेथड स्टब्स,]], [[विधि ठूंठ|मॉक ऑब्जेक्ट्स,]]फेक और टेस्ट हार्नेस जैसे सब्स्टीट्यूट्स का उपयोग अलगाव में मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।।
+विकास के दौरान, एक सॉफ्टवेयर डेवलपर इकाई की शुद्धता को सत्यापित करने के लिए परीक्षण में मापदंड, या परिणाम जो अच्छे माने जाते हैं, को कोड कर सकता है। टेस्ट केस एक्जीक्यूशन के दौरान, फ्रेमवर्क [[कंप्यूटर डेटा लॉगिंग]] टेस्ट जो किसी भी मानदंड को विफल करते हैं और उन्हें सारांश में रिपोर्ट करते हैं। इसके लिए, सबसे अधिक उपयोग किया जाने वाला विधि टेस्ट-फंक्शन-अपेक्षित मूल्य है।
+[[पैरामीटरयुक्त परीक्षण]] का उपयोग करके इकाई परीक्षणों को लिखना और बनाए रखना तेजी से बनाया जा सकता है। ये विभिन्न इनपुट सेटों के सापेक्ष एक परीक्षण को कई बार निष्पादित करने की अनुमति देते हैं, इस प्रकार परीक्षण कोड दोहराव को न्यूनतम करते हैं। पारंपरिक इकाई परीक्षणों के विपरीत, जो आमतौर पर बंद विधि हैं और अपरिवर्तनीय स्थितियों का परीक्षण करते हैं, पैरामीटरयुक्त परीक्षण पैरामीटर के किसी भी सेट को लेते हैं। Parameterized परीक्षण [[TestNG]], JUnit और इसके .Net समकक्ष, [[XUnit]] द्वारा समर्थित हैं। इकाई परीक्षणों के लिए उपयुक्त पैरामीटर मैन्युअल रूप से आपूर्ति किए जा सकते हैं या कुछ घटनाओं में स्वचालित रूप से परीक्षण ढांचे द्वारा उत्पन्न होते हैं। हाल के वर्षों में अधिक शक्तिशाली (इकाई) परीक्षण लिखने, सिद्धांतों की अवधारणा का लाभ उठाने, समान चरणों को निष्पादित करने वाले परीक्षण मामलों के लिए समर्थन जोड़ा गया था, परंतु रनटाइम पर उत्पन्न परीक्षण डेटा का उपयोग करते हुए, नियमित पैरामीटरयुक्त परीक्षणों के विपरीत, जो इनपुट सेट के सापेक्ष समान निष्पादन चरणों का उपयोग करते हैं जो पूर्व निर्धारित हैं।<ref>{{Cite web|url=https://xunit.github.io/docs/getting-started-desktop.html|title=Getting Started with xUnit.net (desktop)}}</ref><ref>{{Cite web|url=https://github.com/junit-team/junit4/wiki/सिद्धांतों|title=सिद्धांतों|website=[[GitHub]]}}</ref><ref>{{Cite web|url=https://github.com/junit-team/junit4/wiki/Parameterized-tests|title=पैरामीटरयुक्त परीक्षण|website=[[GitHub]]}}</ref>
-[[पैरामीटरयुक्त परीक्षण]]ों का उपयोग करके यूनिट परीक्षणों को लिखना और बनाए रखना तेजी से बनाया जा सकता है। ये विभिन्न इनपुट सेटों के साथ एक परीक्षण को कई बार निष्पादित करने की अनुमति देते हैं, इस प्रकार परीक्षण कोड दोहराव को कम करते हैं। पारंपरिक इकाई परीक्षणों के विपरीत, जो आमतौर पर बंद तरीके हैं और अपरिवर्तनीय स्थितियों का परीक्षण करते हैं, पैरामीटरयुक्त परीक्षण पैरामीटर के किसी भी सेट को लेते हैं। Parameterized परीक्षण [[TestNG]], JUnit और इसके .Net समकक्ष, [[XUnit]] द्वारा समर्थित हैं। यूनिट परीक्षणों के लिए उपयुक्त पैरामीटर मैन्युअल रूप से आपूर्ति किए जा सकते हैं या कुछ मामलों में स्वचालित रूप से परीक्षण ढांचे द्वारा उत्पन्न होते हैं। हाल के वर्षों में अधिक शक्तिशाली (यूनिट) परीक्षण लिखने, सिद्धांतों की अवधारणा का लाभ उठाने, समान चरणों को निष्पादित करने वाले परीक्षण मामलों के लिए समर्थन जोड़ा गया था, लेकिन रनटाइम पर उत्पन्न परीक्षण डेटा का उपयोग करते हुए, नियमित पैरामीटरयुक्त परीक्षणों के विपरीत, जो इनपुट सेट के साथ समान निष्पादन चरणों का उपयोग करते हैं जो पूर्व निर्धारित हैं।<ref>{{Cite web|url=https://xunit.github.io/docs/getting-started-desktop.html|title=Getting Started with xUnit.net (desktop)}}</ref><ref>{{Cite web|url=https://github.com/junit-team/junit4/wiki/सिद्धांतों|title=सिद्धांतों|website=[[GitHub]]}}</ref><ref>{{Cite web|url=https://github.com/junit-team/junit4/wiki/Parameterized-tests|title=पैरामीटरयुक्त परीक्षण|website=[[GitHub]]}}</ref>
 == लाभ ==
-इकाई परीक्षण का लक्ष्य कार्यक्रम के प्रत्येक भाग को अलग करना है और यह दिखाना है कि अलग-अलग भाग सही हैं।<ref name="kolawa"/>एक इकाई परीक्षण अनुबंध द्वारा एक सख्त, लिखित डिज़ाइन प्रदान करता है जो कोड के टुकड़े को संतुष्ट करना चाहिए। नतीजतन, यह कई लाभ प्रदान करता है।
+इकाई परीक्षण का लक्ष्य कार्यक्रम के प्रत्येक भाग को अलग करना है और यह दिखाना है कि भिन्न -भिन्न  भाग सही हैं।<ref name="kolawa"/>एक इकाई परीक्षण अनुबंध द्वारा एक सख्त, लिखित डिज़ाइन प्रदान करता है जो कोड के टुकड़े को संतुष्ट करना चाहिए। नतीजतन, यह कई लाभ प्रदान करता है।
-यूनिट परीक्षण [[विकास चक्र]] में शुरुआती समस्याओं का पता लगाता है। इसमें प्रोग्रामर के कार्यान्वयन में बग और यूनिट के लिए विनिर्देश के दोष या गायब हिस्से दोनों शामिल हैं। परीक्षणों का एक संपूर्ण सेट लिखने की प्रक्रिया लेखक को इनपुट, आउटपुट और त्रुटि स्थितियों के माध्यम से सोचने के लिए मजबूर करती है, और इस प्रकार इकाई के वांछित व्यवहार को और अधिक स्पष्ट रूप से परिभाषित करती है। कोडिंग शुरू होने से पहले बग को खोजने की लागत या जब कोड पहली बार लिखा जाता है, बाद में बग का पता लगाने, पहचानने और ठीक करने की लागत से काफी कम होता है। जारी किए गए कोड में बग भी सॉफ़्टवेयर के अंतिम-उपयोगकर्ताओं के लिए महंगी समस्याएँ पैदा कर सकते हैं।<ref>{{cite journal |last1=Boehm |first1=Barry W. |author-link1=Barry Boehm|last2=Papaccio |first2=Philip N. |date=October 1988 |title=सॉफ्टवेयर लागत को समझना और नियंत्रित करना|url=http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R6.pdf |journal=IEEE Transactions on Software Engineering |volume=14 |issue=10 |pages=1462–1477 |doi= 10.1109/32.6191|access-date=13 May 2016}}</ref><ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ee330950%28v=vs.110%29.aspx|title=जल्दी और अक्सर परीक्षण करें|publisher=Microsoft}}</ref><ref>{{cite web|url=http://www.ni.com/white-paper/8082/en/| title=Prove It Works: Using the Unit Test Framework for Software Testing and Validation| publisher=[[National Instruments]]| date=2017-08-21}}</ref> खराब लिखे जाने पर यूनिट परीक्षण के लिए कोड असंभव या कठिन हो सकता है, इस प्रकार यूनिट परीक्षण डेवलपर्स को बेहतर तरीके से संरचना कार्यों और वस्तुओं के लिए मजबूर कर सकता है।
+इकाई परीक्षण [[विकास चक्र]] में शुरुआती समस्याओं का पता लगाता है। इसमें प्रोग्रामर के कार्यान्वयन में बग और इकाई के लिए विनिर्देश के दोष या गायब हिस्से दोनों सम्मिलितहैं। परीक्षणों का एक संपूर्ण सेट लिखने की प्रक्रिया लेखक को इनपुट, आउटपुट और त्रुटि स्थितियों के माध्यम से सोचने के लिए मजबूर करती है, और इस प्रकार इकाई के वांछित व्यवहार को और अधिक स्पष्ट रूप से परिभाषित करती है। कोडिंग शुरू होने से पहले बग को खोजने की लागत या जब कोड पहली बार लिखा जाता है, बाद में बग का पता लगाने, पहचानने और ठीक करने की लागत से काफी कम होता है। जारी किए गए कोड में बग भी सॉफ़्टवेयर के अंतिम-उपयोगकर्ताओं के लिए महंगी समस्याएँ पैदा कर सकते हैं।<ref>{{cite journal |last1=Boehm |first1=Barry W. |author-link1=Barry Boehm|last2=Papaccio |first2=Philip N. |date=October 1988 |title=सॉफ्टवेयर लागत को समझना और नियंत्रित करना|url=http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R6.pdf |journal=IEEE Transactions on Software Engineering |volume=14 |issue=10 |pages=1462–1477 |doi= 10.1109/32.6191|access-date=13 May 2016}}</ref><ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ee330950%28v=vs.110%29.aspx|title=जल्दी और अक्सर परीक्षण करें|publisher=Microsoft}}</ref><ref>{{cite web|url=http://www.ni.com/white-paper/8082/en/| title=Prove It Works: Using the Unit Test Framework for Software Testing and Validation| publisher=[[National Instruments]]| date=2017-08-21}}</ref> खराब लिखे जाने पर इकाई परीक्षण के लिए कोड असंभव या कठिन हो सकता है, इस प्रकार इकाई परीक्षण डेवलपर्स को बेहतर तरीके से संरचना कार्यों और वस्तुओं के लिए मजबूर कर सकता है।
-परीक्षण-संचालित विकास (टीडीडी) में, जो अक्सर [[चरम कार्यक्रम]] और [[स्क्रम (सॉफ्टवेयर विकास)]] दोनों में उपयोग किया जाता है, कोड लिखे जाने से पहले इकाई परीक्षण बनाए जाते हैं। जब परीक्षण पास हो जाते हैं, तो वह कोड पूर्ण माना जाता है। उसी इकाई परीक्षण को उस फ़ंक्शन के खिलाफ अक्सर चलाया जाता है क्योंकि बड़ा कोड बेस विकसित होता है या तो कोड बदल जाता है या निर्माण के साथ स्वचालित प्रक्रिया के माध्यम से। यदि इकाई परीक्षण विफल हो जाते हैं, तो इसे या तो बदले हुए कोड में या स्वयं परीक्षणों में एक बग माना जाता है। इकाई परीक्षण तब गलती या विफलता के स्थान को आसानी से पता लगाने की अनुमति देता है। चूंकि इकाई परीक्षण समस्या के विकास दल को परीक्षकों या ग्राहकों को कोड सौंपने से पहले सचेत करता है, संभावित समस्याओं को विकास प्रक्रिया में जल्दी पकड़ा जाता है।
+परीक्षण-संचालित विकास (टीडीडी) में, जो  प्रायः [[चरम कार्यक्रम]] और [[स्क्रम (सॉफ्टवेयर विकास)]] दोनों में उपयोग किया जाता है, कोड लिखे जाने से पहले इकाई परीक्षण बनाए जाते हैं। जब परीक्षण पास हो जाते हैं, तो वह कोड पूर्ण माना जाता है। उसी इकाई परीक्षण को उस फ़ंक्शन के खिलाफ  प्रायः चलाया जाता है क्योंकि बड़ा कोड बेस विकसित होता है या तो कोड बदल जाता है या निर्माण के सापेक्षस्वचालित प्रक्रिया के माध्यम से। यदि इकाई परीक्षण विफल हो जाते हैं, तो इसे या तो बदले हुए कोड में या स्वयं परीक्षणों में एक बग माना जाता है। इकाई परीक्षण तब गलती या विफलता के स्थान को आसानी से पता लगाने की अनुमति देता है। चूंकि इकाई परीक्षण समस्या के विकास दल को परीक्षकों या ग्राहकों को कोड सौंपने से पहले सचेत करता है, संभावित समस्याओं को विकास प्रक्रिया में जल्दी पकड़ा जाता है।
-यूनिट परीक्षण प्रोग्रामर को बाद की तारीख में कोड को [[पुनर्रचना]] या सिस्टम लाइब्रेरी को अपग्रेड करने की अनुमति देता है, और यह सुनिश्चित करता है कि मॉड्यूल अभी भी सही तरीके से काम करता है (उदाहरण के लिए, [[प्रतिगमन परीक्षण]] में)। प्रक्रिया सभी [[सबरूटीन]]्स और [[विधि (कंप्यूटर विज्ञान)]] के लिए टेस्ट केस लिखने के लिए है ताकि जब भी कोई बदलाव गलती का कारण बनता है, तो इसे जल्दी से पहचाना जा सके। यूनिट परीक्षण उन परिवर्तनों का पता लगाते हैं जो [[अनुबंध द्वारा डिजाइन]] को तोड़ सकते हैं।
+इकाई परीक्षण प्रोग्रामर को बाद की तारीख में कोड को [[पुनर्रचना]] या सिस्टम लाइब्रेरी को अपग्रेड करने की अनुमति देता है, और यह सुनिश्चित करता है कि मॉड्यूल अभी भी सही तरीके से काम करता है (उदाहरण के लिए, [[प्रतिगमन परीक्षण]] में)। प्रक्रिया सभी [[सबरूटीन]]्स और [[विधि (कंप्यूटर विज्ञान)]] के लिए टेस्ट केस लिखने के लिए है यद्यपि जब भी कोई बदलाव गलती का कारण बनता है, तो इसे जल्दी से पहचाना जा सके। इकाई परीक्षण उन परिवर्तनों का पता लगाते हैं जो [[अनुबंध द्वारा डिजाइन]] को तोड़ सकते हैं।
 इकाई परीक्षण स्वयं इकाइयों में अनिश्चितता को कम कर सकता है और इसका उपयोग [[टॉप-डाउन और बॉटम-अप डिज़ाइन]] | बॉटम-अप परीक्षण शैली दृष्टिकोण में किया जा सकता है। किसी प्रोग्राम के भागों का पहले परीक्षण करके और फिर उसके भागों के योग का परीक्षण करके, एकीकरण परीक्षण बहुत आसान हो जाता है।{{Citation needed|date=January 2013}}
-यूनिट परीक्षण प्रणाली का एक प्रकार का जीवित दस्तावेज प्रदान करता है। यूनिट द्वारा कौन सी कार्यक्षमता प्रदान की जाती है, और इसका उपयोग कैसे करना है, यह जानने के इच्छुक डेवलपर्स यूनिट के इंटरफ़ेस ([[अप्लिकेशन प्रोग्रामिंग अंतरफलक]]) की बुनियादी समझ हासिल करने के लिए यूनिट परीक्षण देख सकते हैं।{{Citation needed|date=September 2019}}
+इकाई परीक्षण प्रणाली का एक प्रकार का जीवित दस्तावेज प्रदान करता है। इकाई द्वारा कौन सी कार्यक्षमता प्रदान की जाती है, और इसका उपयोग कैसे करना है, यह जानने के इच्छुक डेवलपर्स इकाई के इंटरफ़ेस ([[अप्लिकेशन प्रोग्रामिंग अंतरफलक]]) की बुनियादी समझ हासिल करने के लिए इकाई परीक्षण देख सकते हैं।{{Citation needed|date=September 2019}}
-इकाई परीक्षण के मामले उन विशेषताओं को शामिल करते हैं जो इकाई की सफलता के लिए महत्वपूर्ण हैं। ये विशेषताएँ एक इकाई के उचित/अनुचित उपयोग के साथ-साथ नकारात्मक व्यवहारों को इंगित कर सकती हैं जिन्हें इकाई द्वारा फंसाया जाना है। एक इकाई परीक्षण मामला, अपने आप में, इन महत्वपूर्ण विशेषताओं को प्रलेखित करता है, हालांकि कई सॉफ्टवेयर विकास वातावरण विकास में उत्पाद को प्रलेखित करने के लिए केवल कोड पर निर्भर नहीं होते हैं।{{Citation needed|date=September 2019}}
+इकाई परीक्षण के मामले उन विशेषताओं को सम्मिलितकरते हैं जो इकाई की सफलता के लिए महत्वपूर्ण हैं। ये विशेषताएँ एक इकाई के उचित/अनुचित उपयोग के साथ-सापेक्षनकारात्मक व्यवहारों को इंगित कर सकती हैं जिन्हें इकाई द्वारा फंसाया जाना है। एक इकाई परीक्षण मामला, अपने आप में, इन महत्वपूर्ण विशेषताओं को प्रलेखित करता है, हालांकि कई सॉफ्टवेयर विकास वातावरण विकास में उत्पाद को प्रलेखित करने के लिए केवल कोड पर निर्भर नहीं होते हैं।{{Citation needed|date=September 2019}}
-जब परीक्षण-संचालित दृष्टिकोण का उपयोग करके सॉफ़्टवेयर विकसित किया जाता है, तो इंटरफ़ेस निर्दिष्ट करने के लिए यूनिट टेस्ट लिखने का संयोजन और परीक्षण पारित होने के बाद की गई रीफैक्टरिंग गतिविधियां औपचारिक डिजाइन की जगह ले सकती हैं। प्रत्येक इकाई परीक्षण को कक्षाओं, विधियों और अवलोकनीय व्यवहार को निर्दिष्ट करने वाले एक डिजाइन तत्व के रूप में देखा जा सकता है।{{Citation needed|date=September 2019}}
+जब परीक्षण-संचालित दृष्टिकोण का उपयोग करके सॉफ़्टवेयर विकसित किया जाता है, तो इंटरफ़ेस निर्दिष्ट करने के लिए इकाई टेस्ट लिखने का संयोजन और परीक्षण पारित होने के बाद की गई रीफैक्टरिंग गतिविधियां औपचारिक डिजाइन की जगह ले सकती हैं। प्रत्येक इकाई परीक्षण को कक्षाओं, विधियों और अवलोकनीय व्यवहार को निर्दिष्ट करने वाले एक डिजाइन तत्व के रूप में देखा जा सकता है।{{Citation needed|date=September 2019}}
 == सीमाएं और नुकसान ==
-परीक्षण कार्यक्रम में हर त्रुटि को नहीं पकड़ेगा, क्योंकि यह किसी भी निष्पादन पथ का मूल्यांकन नहीं कर सकता है लेकिन सबसे तुच्छ कार्यक्रम है। यह [[निर्णय समस्या]] हॉल्टिंग समस्या का सुपरसेट है, जो कि [[अनिर्णीत समस्या]] है। इकाई परीक्षण के लिए भी यही सच है। इसके अतिरिक्त, परिभाषा के अनुसार इकाई परीक्षण केवल स्वयं इकाइयों की कार्यक्षमता का परीक्षण करता है। इसलिए, यह एकीकरण त्रुटियों या व्यापक सिस्टम-स्तरीय त्रुटियों को नहीं पकड़ेगा (जैसे कि कई इकाइयों में किए गए कार्य, या गैर-कार्यात्मक परीक्षण क्षेत्र जैसे सॉफ़्टवेयर प्रदर्शन परीक्षण)। यूनिट परीक्षण अन्य सॉफ्टवेयर परीक्षण गतिविधियों के संयोजन में किया जाना चाहिए, क्योंकि वे केवल विशेष त्रुटियों की उपस्थिति या अनुपस्थिति दिखा सकते हैं; वे त्रुटियों के पूर्ण अभाव को साबित नहीं कर सकते। प्रत्येक निष्पादन पथ और हर संभव इनपुट के लिए सही व्यवहार की गारंटी देने के लिए, और त्रुटियों की अनुपस्थिति को सुनिश्चित करने के लिए, अन्य तकनीकों की आवश्यकता होती है, अर्थात् यह साबित करने के लिए [[औपचारिक सत्यापन]] का अनुप्रयोग कि सॉफ़्टवेयर घटक में कोई अप्रत्याशित व्यवहार नहीं है।{{Citation needed|date=September 2019}}
+परीक्षण कार्यक्रम में हर त्रुटि को नहीं पकड़ेगा, क्योंकि यह किसी भी निष्पादन पथ का मूल्यांकन नहीं कर सकता है परंतु सबसे तुच्छ कार्यक्रम है। यह [[निर्णय समस्या]] हॉल्टिंग समस्या का सुपरसेट है, जो कि [[अनिर्णीत समस्या]] है। इकाई परीक्षण के लिए भी यही सच है। इसके अतिरिक्त, परिभाषा के अनुसार इकाई परीक्षण केवल स्वयं इकाइयों की कार्यक्षमता का परीक्षण करता है। इसलिए, यह एकीकरण त्रुटियों या व्यापक सिस्टम-स्तरीय त्रुटियों को नहीं पकड़ेगा (जैसे कि कई इकाइयों में किए गए कार्य, या गैर-कार्यात्मक परीक्षण क्षेत्र जैसे सॉफ़्टवेयर प्रदर्शन परीक्षण)। इकाई परीक्षण अन्य सॉफ्टवेयर परीक्षण गतिविधियों के संयोजन में किया जाना चाहिए, क्योंकि वे केवल विशेष त्रुटियों की उपस्थिति या अनुपस्थिति दिखा सकते हैं; वे त्रुटियों के पूर्ण अभाव को साबित नहीं कर सकते। प्रत्येक निष्पादन पथ और हर संभव इनपुट के लिए सही व्यवहार की गारंटी देने के लिए, और त्रुटियों की अनुपस्थिति को सुनिश्चित करने के लिए, अन्य तकनीकों की आवश्यकता होती है, अर्थात् यह साबित करने के लिए [[औपचारिक सत्यापन]] का अनुप्रयोग कि सॉफ़्टवेयर घटक में कोई अप्रत्याशित व्यवहार नहीं है।{{Citation needed|date=September 2019}}
-यूनिट परीक्षणों का एक विस्तृत पदानुक्रम एकीकरण परीक्षण के बराबर नहीं है। परिधीय इकाइयों के साथ एकीकरण को एकीकरण परीक्षणों में शामिल किया जाना चाहिए, लेकिन इकाई परीक्षणों में नहीं।{{Citation needed|date=October 2010}} एकीकरण परीक्षण आमतौर पर अभी भी मानव के [[मैनुअल परीक्षण]] पर बहुत अधिक निर्भर करता है; उच्च-स्तरीय या वैश्विक-दायरे के परीक्षण को स्वचालित करना मुश्किल हो सकता है, जैसे मैन्युअल परीक्षण अक्सर तेज़ और सस्ता दिखाई देता है।{{Citation needed|date=January 2010}}
+इकाई परीक्षणों का एक विस्तृत पदानुक्रम एकीकरण परीक्षण के बराबर नहीं है। परिधीय इकाइयों के सापेक्षएकीकरण को एकीकरण परीक्षणों में सम्मिलितकिया जाना चाहिए, परंतु इकाई परीक्षणों में नहीं।{{Citation needed|date=October 2010}} एकीकरण परीक्षण आमतौर पर अभी भी मानव के [[मैनुअल परीक्षण]] पर बहुत अधिक निर्भर करता है; उच्च-स्तरीय या वैश्विक-दायरे के परीक्षण को स्वचालित करना मुश्किल हो सकता है, जैसे मैन्युअल परीक्षण  प्रायः तेज़ और सस्ता दिखाई देता है।{{Citation needed|date=January 2010}}
-सॉफ्टवेयर परीक्षण एक मिश्रित समस्या है। उदाहरण के लिए, प्रत्येक बूलियन निर्णय कथन के लिए कम से कम दो परीक्षणों की आवश्यकता होती है: एक सत्य के परिणाम के साथ और एक गलत के परिणाम के साथ। परिणामस्वरूप, लिखे गए कोड की प्रत्येक पंक्ति के लिए, प्रोग्रामर को अक्सर टेस्ट कोड की 3 से 5 पंक्तियों की आवश्यकता होती है।<ref>{{cite web|last=Cramblitt|first=Bob|author-link=Bob Cramblitt| title=अल्बर्टो सावोइया सॉफ्टवेयर परीक्षण की प्रशंसा करता है|date=2007-09-20| access-date=2007-11-29|url=http://searchsoftwarequality.techtarget.com/originalContent/0,289142,sid92_gci1273161,00.html}}</ref> इसमें स्पष्ट रूप से समय लगता है और इसका निवेश प्रयास के लायक नहीं हो सकता है। ऐसी समस्याएं हैं जिनका आसानी से बिल्कुल भी परीक्षण नहीं किया जा सकता है - उदाहरण के लिए वे जो [[गैर नियतात्मक एल्गोरिथम]] हैं या जिसमें कई थ्रेड (कंप्यूटर साइंस) शामिल हैं। इसके अलावा, यूनिट परीक्षण के लिए कोड उतना ही छोटा होने की संभावना है जितना कोड परीक्षण कर रहा है। [[द मिथिकल मैन-मंथ]] में [[फ्रेड ब्रूक्स]] उद्धरण: कभी भी दो क्रोनोमीटर के साथ समुद्र में न जाएं; एक या तीन लो।<ref>{{Cite book | isbn = 978-0-201-83595-3 | title = द मिथिकल मैन-मंथ| last = Brooks | first = Frederick J. | author-link = Fred Brooks | year = 1995 | orig-year = 1975 | publisher = Addison-Wesley | page = [https://archive.org/details/mythicalmonth00broo/page/64 64] | title-link = द मिथिकल मैन-मंथ}}</ref> मतलब, अगर दो [[समुद्री क्रोनोमीटर]] विरोधाभासी हैं, तो आप कैसे जानेंगे कि कौन सा सही है?
+सॉफ्टवेयर परीक्षण एक मिश्रित समस्या है। उदाहरण के लिए, प्रत्येक बूलियन निर्णय कथन के लिए कम से कम दो परीक्षणों की आवश्यकता होती है: एक सत्य के परिणाम के सापेक्षऔर एक गलत के परिणाम के साथ। परिणामस्वरूप, लिखे गए कोड की प्रत्येक पंक्ति के लिए, प्रोग्रामर को  प्रायः टेस्ट कोड की 3 से 5 पंक्तियों की आवश्यकता होती है।<ref>{{cite web|last=Cramblitt|first=Bob|author-link=Bob Cramblitt| title=अल्बर्टो सावोइया सॉफ्टवेयर परीक्षण की प्रशंसा करता है|date=2007-09-20| access-date=2007-11-29|url=http://searchsoftwarequality.techtarget.com/originalContent/0,289142,sid92_gci1273161,00.html}}</ref> इसमें स्पष्ट रूप से समय लगता है और इसका निवेश प्रयास के लायक नहीं हो सकता है। ऐसी समस्याएं हैं जिनका आसानी से बिल्कुल भी परीक्षण नहीं किया जा सकता है - उदाहरण के लिए वे जो [[गैर नियतात्मक एल्गोरिथम]] हैं या जिसमें कई थ्रेड (कंप्यूटर साइंस) सम्मिलितहैं। इसके अलावा, इकाई परीक्षण के लिए कोड उतना ही छोटा होने की संभावना है जितना कोड परीक्षण कर रहा है। [[द मिथिकल मैन-मंथ]] में [[फ्रेड ब्रूक्स]] उद्धरण: कभी भी दो क्रोनोमीटर के सापेक्षसमुद्र में न जाएं; एक या तीन लो।<ref>{{Cite book | isbn = 978-0-201-83595-3 | title = द मिथिकल मैन-मंथ| last = Brooks | first = Frederick J. | author-link = Fred Brooks | year = 1995 | orig-year = 1975 | publisher = Addison-Wesley | page = [https://archive.org/details/mythicalmonth00broo/page/64 64] | title-link = द मिथिकल मैन-मंथ}}</ref> मतलब, अगर दो [[समुद्री क्रोनोमीटर]] विरोधाभासी हैं, तो आप कैसे जानेंगे कि कौन सा सही है?
-इकाई परीक्षण लिखने से जुड़ी एक अन्य चुनौती यथार्थवादी और उपयोगी परीक्षण स्थापित करने की कठिनाई है। प्रासंगिक प्रारंभिक स्थितियां बनाना आवश्यक है ताकि परीक्षण किए जा रहे एप्लिकेशन का हिस्सा पूरी प्रणाली के हिस्से की तरह व्यवहार करे। यदि इन प्रारंभिक स्थितियों को सही ढंग से सेट नहीं किया गया है, तो परीक्षण यथार्थवादी संदर्भ में कोड का प्रयोग नहीं करेगा, जो इकाई परीक्षण परिणामों के मूल्य और सटीकता को कम करता है।<ref>{{cite web|last=Kolawa|first=Adam|author-link=Adam Kolawa| title=यूनिट परीक्षण सर्वोत्तम अभ्यास|date=2009-07-01| access-date=2012-07-23|url=http://www.parasoft.com/unit-testing-best-practices}}</ref>
+इकाई परीक्षण लिखने से जुड़ी एक अन्य चुनौती यथार्थवादी और उपयोगी परीक्षण स्थापित करने की कठिनाई है। प्रासंगिक प्रारंभिक स्थितियां बनाना आवश्यक है यद्यपि परीक्षण किए जा रहे एप्लिकेशन का हिस्सा पूरी प्रणाली के हिस्से की तरह व्यवहार करे। यदि इन प्रारंभिक स्थितियों को सही ढंग से सेट नहीं किया गया है, तो परीक्षण यथार्थवादी संदर्भ में कोड का प्रयोग नहीं करेगा, जो इकाई परीक्षण परिणामों के मूल्य और सटीकता को कम करता है।<ref>{{cite web|last=Kolawa|first=Adam|author-link=Adam Kolawa| title=यूनिट परीक्षण सर्वोत्तम अभ्यास|date=2009-07-01| access-date=2012-07-23|url=http://www.parasoft.com/unit-testing-best-practices}}</ref>
 इकाई परीक्षण से इच्छित लाभ प्राप्त करने के लिए, सॉफ्टवेयर विकास प्रक्रिया के दौरान कठोर अनुशासन की आवश्यकता होती है। न केवल किए गए परीक्षणों का सावधानीपूर्वक रिकॉर्ड रखना आवश्यक है, बल्कि इस या सॉफ़्टवेयर की किसी अन्य इकाई के स्रोत कोड में किए गए सभी परिवर्तनों का भी रिकॉर्ड रखना आवश्यक है। एक [[संस्करण नियंत्रण]] प्रणाली का उपयोग आवश्यक है। यदि इकाई का बाद का संस्करण किसी विशेष परीक्षण में विफल रहता है जिसे वह पहले पारित कर चुका था, तो संस्करण-नियंत्रण सॉफ़्टवेयर स्रोत कोड परिवर्तनों (यदि कोई हो) की एक सूची प्रदान कर सकता है जो उस समय से इकाई पर लागू किए गए हैं।{{Citation needed|date=September 2019}}
-यह सुनिश्चित करने के लिए एक स्थायी प्रक्रिया को लागू करना भी आवश्यक है कि परीक्षण मामले की विफलताओं की नियमित रूप से समीक्षा की जाती है और तुरंत संबोधित किया जाता है।<ref>{{cite web|last=daVeiga|first=Nada|author-link=Nada daVeiga| title=Change Code Without Fear: Utilize a regression safety net|date=2008-02-06| access-date=2008-02-08|url=http://www.ddj.com/development-tools/206105233}}</ref> यदि इस तरह की प्रक्रिया को लागू नहीं किया जाता है और टीम के वर्कफ़्लो में शामिल हो जाता है, तो एप्लिकेशन यूनिट टेस्ट सूट के साथ सिंक से बाहर हो जाएगा, झूठी सकारात्मकता बढ़ जाएगी और टेस्ट सूट की प्रभावशीलता कम हो जाएगी।
+यह सुनिश्चित करने के लिए एक स्थायी प्रक्रिया को लागू करना भी आवश्यक है कि परीक्षण मामले की विफलताओं की नियमित रूप से समीक्षा की जाती है और तुरंत संबोधित किया जाता है।<ref>{{cite web|last=daVeiga|first=Nada|author-link=Nada daVeiga| title=Change Code Without Fear: Utilize a regression safety net|date=2008-02-06| access-date=2008-02-08|url=http://www.ddj.com/development-tools/206105233}}</ref> यदि इस तरह की प्रक्रिया को लागू नहीं किया जाता है और टीम के वर्कफ़्लो में सम्मिलितहो जाता है, तो एप्लिकेशन इकाई टेस्ट सूट के सापेक्षसिंक से बाहर हो जाएगा, झूठी सकारात्मकता बढ़ जाएगी और टेस्ट सूट की प्रभावशीलता कम हो जाएगी।
-यूनिट परीक्षण एम्बेडेड सिस्टम सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक अलग प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के साथ संभव है।<ref>{{cite web|last=Kucharski|first=Marek|author-link=Marek Kucharski| title=अंतःस्थापित विकास के लिए इकाई परीक्षण को व्यावहारिक बनाना|date=2011-11-23| access-date=2020-07-20|url=https://www.electronicdesign.com/technologies/embedded-revolution/article/21794376/making-unit-testing-practical-for-embedded-development}}</ref>
+इकाई परीक्षण एम्बेडेड सिस्टम सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक अलग प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्षसंभव है।<ref>{{cite web|last=Kucharski|first=Marek|author-link=Marek Kucharski| title=अंतःस्थापित विकास के लिए इकाई परीक्षण को व्यावहारिक बनाना|date=2011-11-23| access-date=2020-07-20|url=https://www.electronicdesign.com/technologies/embedded-revolution/article/21794376/making-unit-testing-practical-for-embedded-development}}</ref>
-यूनिट परीक्षण सबसे आसान होते हैं जब किसी विधि में इनपुट पैरामीटर और कुछ आउटपुट होते हैं। इकाई परीक्षण बनाना उतना आसान नहीं है जब विधि का एक प्रमुख कार्य अनुप्रयोग के लिए किसी बाहरी चीज़ के साथ सहभागिता करना हो। उदाहरण के लिए, एक विधि जो डेटाबेस के साथ काम करेगी, उसे बनाने के लिए डेटाबेस इंटरैक्शन के मॉक अप की आवश्यकता हो सकती है, जो संभवतः वास्तविक डेटाबेस इंटरैक्शन के रूप में व्यापक नहीं होगा।<ref>http://wiki.c2.com/?UnitTestsAndDatabases {{Bare URL inline|date=August 2022}}</ref>{{better source needed|date=February 2019}}
+इकाई परीक्षण सबसे आसान होते हैं जब किसी विधि में इनपुट पैरामीटर और कुछ आउटपुट होते हैं। इकाई परीक्षण बनाना उतना आसान नहीं है जब विधि का एक प्रमुख कार्य अनुप्रयोग के लिए किसी बाहरी चीज़ के सापेक्षसहभागिता करना हो। उदाहरण के लिए, एक विधि जो डेटाबेस के सापेक्षकाम करेगी, उसे बनाने के लिए डेटाबेस इंटरैक्शन के मॉक अप की आवश्यकता हो सकती है, जो संभवतः वास्तविक डेटाबेस इंटरैक्शन के रूप में व्यापक नहीं होगा।<ref>http://wiki.c2.com/?UnitTestsAndDatabases {{Bare URL inline|date=August 2022}}</ref>{{better source needed|date=February 2019}}
 == उदाहरण ==
-यहाँ जावा (प्रोग्रामिंग भाषा) में परीक्षण मामलों का एक सेट है जो कार्यान्वयन के कई तत्वों को निर्दिष्ट करता है। सबसे पहले, एडर नामक एक इंटरफ़ेस होना चाहिए, और एक शून्य-तर्क निर्माता के साथ एक कार्यान्वयन वर्ग जिसे AdderImpl कहा जाता है। यह [[अभिकथन (कंप्यूटिंग)]] पर जाता है कि योजक इंटरफ़ेस में दो पूर्णांक मापदंडों के साथ ऐड नामक एक विधि होनी चाहिए, जो एक और पूर्णांक लौटाती है। यह कई परीक्षण विधियों पर मूल्यों की एक छोटी श्रृंखला के लिए इस पद्धति के व्यवहार को भी निर्दिष्ट करता है।
+यहाँ जावा (प्रोग्रामिंग भाषा) में परीक्षण मामलों का एक सेट है जो कार्यान्वयन के कई तत्वों को निर्दिष्ट करता है। सबसे पहले, एडर नामक एक इंटरफ़ेस होना चाहिए, और एक शून्य-तर्क निर्माता के सापेक्षएक कार्यान्वयन वर्ग जिसे AdderImpl कहा जाता है। यह [[अभिकथन (कंप्यूटिंग)]] पर जाता है कि योजक इंटरफ़ेस में दो पूर्णांक मापदंडों के सापेक्षऐड नामक एक विधि होनी चाहिए, जो एक और पूर्णांक लौटाती है। यह कई परीक्षण विधियों पर मूल्यों की एक छोटी श्रृंखला के लिए इस पद्धति के व्यवहार को भी निर्दिष्ट करता है।
 <syntaxhighlight lang="java">
@@ Line 117: / Line 117: @@
 </syntaxhighlight>
-इस मामले में इकाई परीक्षण, पहले लिखे जाने के बाद, एक वांछित समाधान के रूप और व्यवहार को निर्दिष्ट करने वाले एक डिज़ाइन दस्तावेज़ के रूप में कार्य करता है, लेकिन कार्यान्वयन विवरण नहीं, जो प्रोग्रामर के लिए छोड़ दिया जाता है। सबसे आसान काम करने का पालन करना जो संभवत: अभ्यास का काम कर सकता है, सबसे आसान समाधान जो टेस्ट पास करेगा, नीचे दिखाया गया है।
+इस मामले में इकाई परीक्षण, पहले लिखे जाने के बाद, एक वांछित समाधान के रूप और व्यवहार को निर्दिष्ट करने वाले एक डिज़ाइन दस्तावेज़ के रूप में कार्य करता है, परंतु कार्यान्वयन विवरण नहीं, जो प्रोग्रामर के लिए छोड़ दिया जाता है। सबसे आसान काम करने का पालन करना जो संभवत: अभ्यास का काम कर सकता है, सबसे आसान समाधान जो टेस्ट पास करेगा, नीचे दिखाया गया है।
 <syntaxhighlight lang="java">
@@ Line 132: / Line 132: @@
 == निष्पादन योग्य विनिर्देशों के रूप में ==
-{{unreferenced section|date=September 2019}}
-डिज़ाइन विनिर्देश के रूप में यूनिट-टेस्ट का उपयोग करने से अन्य डिज़ाइन विधियों पर एक महत्वपूर्ण लाभ होता है: डिज़ाइन दस्तावेज़ (यूनिट-परीक्षण स्वयं) का उपयोग कार्यान्वयन को सत्यापित करने के लिए किया जा सकता है। जब तक डेवलपर डिजाइन के अनुसार समाधान लागू नहीं करता तब तक परीक्षण कभी पास नहीं होंगे।
-यूनिट परीक्षण में [[एकीकृत मॉडलिंग भाषा]] आरेख जैसे डायग्रामेटिक विनिर्देश की कुछ पहुंच की कमी है, लेकिन वे स्वचालित टूल का उपयोग करके यूनिट परीक्षण से उत्पन्न हो सकते हैं। अधिकांश आधुनिक भाषाओं में नि: शुल्क उपकरण होते हैं (आमतौर पर एकीकृत विकास परिवेशों के विस्तार के रूप में उपलब्ध होते हैं)। नि: शुल्क उपकरण, जैसे कि xUnit ढांचे पर आधारित, मानव उपभोग के लिए एक दृश्य के चित्रमय प्रतिपादन के लिए किसी अन्य प्रणाली को आउटसोर्स करते हैं।
+डिज़ाइन विनिर्देश के रूप में इकाई-टेस्ट का उपयोग करने से अन्य डिज़ाइन विधियों पर एक महत्वपूर्ण लाभ होता है: डिज़ाइन दस्तावेज़ (इकाई-परीक्षण स्वयं) का उपयोग कार्यान्वयन को सत्यापित करने के लिए किया जा सकता है। जब तक डेवलपर डिजाइन के अनुसार समाधान लागू नहीं करता तब तक परीक्षण कभी पास नहीं होंगे।
+इकाई परीक्षण में [[एकीकृत मॉडलिंग भाषा]] आरेख जैसे डायग्रामेटिक विनिर्देश की कुछ पहुंच की कमी है, परंतु वे स्वचालित टूल का उपयोग करके इकाई परीक्षण से उत्पन्न हो सकते हैं। अधिकांश आधुनिक भाषाओं में नि: शुल्क उपकरण होते हैं (आमतौर पर एकीकृत विकास परिवेशों के विस्तार के रूप में उपलब्ध होते हैं)। नि: शुल्क उपकरण, जैसे कि xUnit ढांचे पर आधारित, मानव उपभोग के लिए एक दृश्य के चित्रमय प्रतिपादन के लिए किसी अन्य प्रणाली को आउटसोर्स करते हैं।
 == अनुप्रयोग ==
 === चरम प्रोग्रामिंग ===
-यूनिट टेस्टिंग एक्सट्रीम प्रोग्रामिंग की आधारशिला है[[इकाई परीक्षण ढांचे की सूची]] की एक स्वचालित सूची पर निर्भर करती है। यह स्वचालित इकाई परीक्षण ढांचा या तो तृतीय पक्ष हो सकता है, उदाहरण के लिए, xUnit, या विकास समूह के भीतर बनाया गया।
+इकाई टेस्टिंग एक्सट्रीम प्रोग्रामिंग की आधारशिला है[[इकाई परीक्षण ढांचे की सूची]] की एक स्वचालित सूची पर निर्भर करती है। यह स्वचालित इकाई परीक्षण ढांचा या तो तृतीय पक्ष हो सकता है, उदाहरण के लिए, xUnit, या विकास समूह के भीतर बनाया गया।
 चरम प्रोग्रामिंग परीक्षण-संचालित विकास के लिए इकाई परीक्षणों के निर्माण का उपयोग करती है। डेवलपर एक इकाई परीक्षण लिखता है जो सॉफ़्टवेयर आवश्यकता या दोष को उजागर करता है। यह परीक्षण विफल हो जाएगा क्योंकि या तो आवश्यकता अभी तक लागू नहीं हुई है, या क्योंकि यह जानबूझकर मौजूदा कोड में एक दोष को उजागर करता है। फिर, डेवलपर परीक्षण करने के लिए सबसे सरल कोड लिखता है, अन्य परीक्षणों के साथ, पास करता है।
-सिस्टम में अधिकांश कोड यूनिट टेस्टेड होते हैं, लेकिन जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, लेकिन यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।{{Citation needed|date=November 2008}} एक्सट्रीम प्रोग्रामिंग केवल यह पहचानती है कि परीक्षण शायद ही कभी संपूर्ण होता है (क्योंकि यह आर्थिक रूप से व्यवहार्य होने के लिए अक्सर बहुत महंगा और समय लेने वाला होता है) और सीमित संसाधनों को प्रभावी ढंग से केंद्रित करने के तरीके पर मार्गदर्शन प्रदान करता है।
+सिस्टम में अधिकांश कोड इकाई टेस्टेड होते हैं, परंतु जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, परंतु यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।{{Citation needed|date=November 2008}} एक्सट्रीम प्रोग्रामिंग केवल यह पहचानती है कि परीक्षण शायद ही कभी संपूर्ण होता है (क्योंकि यह आर्थिक रूप से व्यवहार्य होने के लिए  प्रायः बहुत महंगा और समय लेने वाला होता है) और सीमित संसाधनों को प्रभावी ढंग से केंद्रित करने के तरीके पर मार्गदर्शन प्रदान करता है।
-महत्वपूर्ण रूप से, परीक्षण कोड को प्रथम श्रेणी का प्रोजेक्ट आर्टिफैक्ट माना जाता है जिसमें इसे कार्यान्वयन कोड के समान गुणवत्ता पर बनाए रखा जाता है, जिसमें सभी दोहराव हटा दिए जाते हैं। डेवलपर्स यूनिट टेस्टिंग कोड को कोड रिपॉजिटरी में उस कोड के साथ जारी करते हैं जो वह परीक्षण करता है। एक्सट्रीम प्रोग्रामिंग का पूर्ण इकाई परीक्षण उपरोक्त लाभों की अनुमति देता है, जैसे कि सरल और अधिक विश्वसनीय कोड विकास और रीफैक्टरिंग, सरलीकृत कोड एकीकरण, सटीक प्रलेखन और अधिक मॉड्यूलर डिज़ाइन। ये इकाई परीक्षण भी प्रतिगमन परीक्षण के रूप में लगातार चलाए जाते हैं।
+महत्वपूर्ण रूप से, परीक्षण कोड को प्रथम श्रेणी का प्रोजेक्ट आर्टिफैक्ट माना जाता है जिसमें इसे कार्यान्वयन कोड के समान गुणवत्ता पर बनाए रखा जाता है, जिसमें सभी दोहराव हटा दिए जाते हैं। डेवलपर्स इकाई टेस्टिंग कोड को कोड रिपॉजिटरी में उस कोड के सापेक्षजारी करते हैं जो वह परीक्षण करता है। एक्सट्रीम प्रोग्रामिंग का पूर्ण इकाई परीक्षण उपरोक्त लाभों की अनुमति देता है, जैसे कि सरल और अधिक विश्वसनीय कोड विकास और रीफैक्टरिंग, सरलीकृत कोड एकीकरण, सटीक प्रलेखन और अधिक मॉड्यूलर डिज़ाइन। ये इकाई परीक्षण भी प्रतिगमन परीक्षण के रूप में लगातार चलाए जाते हैं।
-इमर्जेंट डिज़ाइन की अवधारणा के लिए यूनिट परीक्षण भी महत्वपूर्ण है। जैसा कि [[आकस्मिक डिजाइन]] रिफैक्टरिंग पर बहुत अधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।<ref>{{cite web |url=http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |title=फुर्तीली उभरती डिजाइन|publisher=Agile Sherpa |date=2010-08-03 |access-date=2012-05-08 |url-status=dead |archive-url=https://web.archive.org/web/20120322143534/http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |archive-date=22 March 2012}}</ref>
+इमर्जेंट डिज़ाइन की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि [[आकस्मिक डिजाइन]] रिफैक्टरिंग पर बहुत अधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।<ref>{{cite web |url=http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |title=फुर्तीली उभरती डिजाइन|publisher=Agile Sherpa |date=2010-08-03 |access-date=2012-05-08 |url-status=dead |archive-url=https://web.archive.org/web/20120322143534/http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |archive-date=22 March 2012}}</ref>
-=== यूनिट टेस्टिंग फ्रेमवर्क ===
+=== इकाई टेस्टिंग फ्रेमवर्क ===
 {{See also|List of unit testing frameworks}}
-यूनिट टेस्टिंग फ्रेमवर्क अक्सर तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे यूनिट टेस्टिंग फ्रेमवर्क की सूची के लिए विकसित किए जाने के बाद यूनिट टेस्टिंग की प्रक्रिया को आसान बनाने में मदद करते हैं।
+इकाई टेस्टिंग फ्रेमवर्क  प्रायः तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे इकाई टेस्टिंग फ्रेमवर्क की सूची के लिए विकसित किए जाने के बाद इकाई टेस्टिंग की प्रक्रिया को आसान बनाने में मदद करते हैं।
-क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना यूनिट परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए [[अभिकथन (सॉफ्टवेयर विकास)]], अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना शायद ही कोई नहीं होने से बेहतर है, जबकि एक बार एक ढांचा होने के बाद, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।<ref>{{cite web|url=http://www.bullseye.com/coverage.html|access-date=24 March 2009|title=मध्यवर्ती कवरेज लक्ष्य|author=Bullseye Testing Technology|date=2006–2008}}</ref> कुछ रूपरेखाओं में कई उन्नत इकाई परीक्षण सुविधाएँ गायब हैं या उन्हें हाथ से कोडित किया जाना चाहिए।
+क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना इकाई परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए [[अभिकथन (सॉफ्टवेयर विकास)]], अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना शायद ही कोई नहीं होने से बेहतर है, जबकि एक बार एक ढांचा होने के बाद, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।<ref>{{cite web|url=http://www.bullseye.com/coverage.html|access-date=24 March 2009|title=मध्यवर्ती कवरेज लक्ष्य|author=Bullseye Testing Technology|date=2006–2008}}</ref> कुछ रूपरेखाओं में कई उन्नत इकाई परीक्षण सुविधाएँ गायब हैं या उन्हें हाथ से कोडित किया जाना चाहिए।
 === भाषा-स्तरीय इकाई परीक्षण समर्थन ===
-कुछ प्रोग्रामिंग लैंग्वेज सीधे यूनिट टेस्टिंग को सपोर्ट करती हैं। उनका व्याकरण पुस्तकालय आयात किए बिना इकाई परीक्षणों की प्रत्यक्ष घोषणा की अनुमति देता है (चाहे तृतीय पक्ष या मानक)। इसके अतिरिक्त, यूनिट परीक्षणों की बूलियन स्थितियों को उसी सिंटैक्स में व्यक्त किया जा सकता है जैसे गैर-यूनिट टेस्ट कोड में उपयोग किए जाने वाले बूलियन एक्सप्रेशन, जैसे कि किसके लिए उपयोग किया जाता है {{code| lang = java |if}} और {{code| lang = java |while}} कथन।
+कुछ प्रोग्रामिंग लैंग्वेज सीधे इकाई टेस्टिंग को सपोर्ट करती हैं। उनका व्याकरण पुस्तकालय आयात किए बिना इकाई परीक्षणों की प्रत्यक्ष घोषणा की अनुमति देता है । इसके अतिरिक्त, इकाई परीक्षणों की बूलियन स्थितियों को उसी सिंटैक्स में व्यक्त किया जा सकता है जैसे गैर-इकाई टेस्ट कोड में उपयोग किए जाने वाले बूलियन एक्सप्रेशन, जैसे कि किसके लिए उपयोग किया जाता है {{code| lang = java |if}} और {{code| lang = java |while}} कथन।
-अंतर्निहित इकाई परीक्षण समर्थन वाली भाषाओं में शामिल हैं:
+अंतर्निहित इकाई परीक्षण समर्थन वाली भाषाओं में सम्मिलित हैं:
 {{colbegin|colwidth=20em}}
-* [[कोबरा (प्रोग्रामिंग भाषा)]]
+* [[कोबरा]]
-* [[डी (प्रोग्रामिंग भाषा)]]<ref>{{cite web|title=यूनिट टेस्ट - डी प्रोग्रामिंग लैंग्वेज|url=http://dlang.org/spec/unittest.html|website=D Programming Language|publisher=D Language Foundation|access-date=5 August 2017}}</ref>
+* [[D]]<ref>{{cite web|title=यूनिट टेस्ट - डी प्रोग्रामिंग लैंग्वेज|url=http://dlang.org/spec/unittest.html|website=D Programming Language|publisher=D Language Foundation|access-date=5 August 2017}}</ref>
-* [[जंग (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=http://static.rust-lang.org/doc/master/guide-testing.html|access-date=12 August 2014|title=The Rust Testing Guide (Rust 0.12.0-pre-nightly)|author=The Rust Project Developers|date=2011–2014}}</ref>
+* [[रस्ट]]<ref>{{cite web|url=http://static.rust-lang.org/doc/master/guide-testing.html|access-date=12 August 2014|title=The Rust Testing Guide (Rust 0.12.0-pre-nightly)|author=The Rust Project Developers|date=2011–2014}}</ref>
 {{colend}}
-मानक इकाई परीक्षण ढांचे के समर्थन वाली भाषाओं में शामिल हैं:
+मानक इकाई परीक्षण ढांचे के समर्थन वाली भाषाओं में सम्मिलित हैं:
 {{colbegin|colwidth=20em}}
-* एपेक्स (प्रोग्रामिंग भाषा)
+* एपेक्स
-* [[क्रिस्टल (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=https://crystal-lang.org/api/0.23.1/Spec.html|access-date=18 September 2017|title=क्रिस्टल युक्ति|publisher=crystal-lang.org}}</ref>
+* [[क्रिस्टल]]<ref>{{cite web|url=https://crystal-lang.org/api/0.23.1/Spec.html|access-date=18 September 2017|title=क्रिस्टल युक्ति|publisher=crystal-lang.org}}</ref>
-* एरलांग (प्रोग्रामिंग भाषा)
+* एरलांग
-* [[जाओ (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=http://golang.org/pkg/testing/|access-date=3 December 2013|title=परीक्षण - द गो प्रोग्रामिंग लैंग्वेज|publisher=golang.org}}</ref>
+* [[गो]]<ref>{{cite web|url=http://golang.org/pkg/testing/|access-date=3 December 2013|title=परीक्षण - द गो प्रोग्रामिंग लैंग्वेज|publisher=golang.org}}</ref>
-* [[जूलिया (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=https://docs.julialang.org/en/v1/stdlib/Test/|title=Unit Testing · The Julia Language|access-date=2022-06-15|publisher=docs.julialang.org}}</ref>
+* [[जूलिया]]<ref>{{cite web|url=https://docs.julialang.org/en/v1/stdlib/Test/|title=Unit Testing · The Julia Language|access-date=2022-06-15|publisher=docs.julialang.org}}</ref>
 * लैब व्यू
 * [[मतलब]]
-* [[पायथन (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=https://docs.python.org/3/library/unittest.html|access-date=18 April 2016|title=यूनिटटेस्ट - यूनिट टेस्टिंग फ्रेमवर्क|author=Python Documentation|date=2016}}</ref>
+* [[पायथन]]<ref>{{cite web|url=https://docs.python.org/3/library/unittest.html|access-date=18 April 2016|title=यूनिटटेस्ट - यूनिट टेस्टिंग फ्रेमवर्क|author=Python Documentation|date=2016}}</ref>
-* [[रैकेट (प्रोग्रामिंग भाषा)]]<ref name=Racket_Unit_Testing>{{cite web|last1=Welsh|first1=Noel|last2=Culpepper|first2=Ryan|title=रैकयूनिट: यूनिट परीक्षण|url=http://docs.racket-lang.org/rackunit/index.html|publisher=PLT Design Inc.|access-date=26 February 2019|ref=Racket_Unit_Testing}}</ref><ref name=Racket_Unit_Testing_Main_dist>{{cite web|last1=Welsh|first1=Noel|last2=Culpepper|first2=Ryan|title=रैकेट यूनिट परीक्षण पैकेज रैकेट मुख्य वितरण का हिस्सा है|url=https://pkgs.racket-lang.org/package/rackunit|publisher=PLT Design Inc.|access-date=26 February 2019|ref=Racket_Unit_Testing_Main_dist}}</ref>
+* [[रैकेट]]<ref name=Racket_Unit_Testing>{{cite web|last1=Welsh|first1=Noel|last2=Culpepper|first2=Ryan|title=रैकयूनिट: यूनिट परीक्षण|url=http://docs.racket-lang.org/rackunit/index.html|publisher=PLT Design Inc.|access-date=26 February 2019|ref=Racket_Unit_Testing}}</ref><ref name=Racket_Unit_Testing_Main_dist>{{cite web|last1=Welsh|first1=Noel|last2=Culpepper|first2=Ryan|title=रैकेट यूनिट परीक्षण पैकेज रैकेट मुख्य वितरण का हिस्सा है|url=https://pkgs.racket-lang.org/package/rackunit|publisher=PLT Design Inc.|access-date=26 February 2019|ref=Racket_Unit_Testing_Main_dist}}</ref>
-* [[रूबी (प्रोग्रामिंग भाषा)]]
+* [[रूबी ]]
 रेफरी>{{cite web|url=http://ruby-doc.org/stdlib-2.0.0/libdoc/minitest/rdoc/MiniTest.html|title=न्यूनतम (रूबी 2.0)|publisher=Ruby-Doc.org}}</ref>
 {{colend}}
-कुछ भाषाओं में बिल्ट-इन यूनिट-टेस्टिंग सपोर्ट नहीं है, लेकिन यूनिट टेस्टिंग लाइब्रेरी या फ्रेमवर्क स्थापित हैं। इन भाषाओं में शामिल हैं:
+कुछ भाषाओं में बिल्ट-इन इकाई-टेस्टिंग सपोर्ट नहीं करता है, परंतु इकाई टेस्टिंग लाइब्रेरी या फ्रेमवर्क स्थापित हैं। इन भाषाओं में सम्मिलित हैं:
 {{colbegin|colwidth=20em}}
 * [[एबीएपी]]
 * [[सी ++]]
-* सी शार्प (प्रोग्रामिंग भाषा)|सी#
+*C# (सी शार्प)
-* [[क्लोजर]]<ref name=Clojure_Unit_Testing_Framework>{{cite web|last1=Sierra|first1=Stuart|title=clojure.test के लिए API - क्लोजर v1.6 (स्थिर)|url=https://clojure.github.io/clojure/clojure.test-api.html|access-date=11 February 2015|ref=Clojure_Unit_Testing_Framework}}</ref>
+* [[क्लोजर]]<ref name=Clojure_Unit_Testing_Framework>{{cite web|last1=Sierra|first1=Stuart|title=clojure.test के लिए API - क्लोजर v1.6 (स्थिर)|url=https://clojure.github.io/clojure/clojure.test-api.html|access-date=11 February
-* अमृत (प्रोग्रामिंग भाषा)
+|ref=Clojure_Unit_Testing_Framework}}</ref>
-* जावा (प्रोग्रामिंग भाषा)
+*  एलिक्सिर
+* जावा
 * [[जावास्क्रिप्ट]]
-* [[उद्देश्य सी]]
+* [[ऑब्जेक्टिव सी]]
 * [[पर्ल]]
 * [[पीएचपी]]
 * [[विंडोज पॉवरशेल]]
-रेफरी>{{cite web|url=https://github.com/pester/Pester|access-date=28 January 2016|title=पेस्टर फ्रेमवर्क|website=[[GitHub]]}}</ref>
+{{cite web|url=https://github.com/pester/Pester|access-date=28 January 2016|title=पेस्टर फ्रेमवर्क|website=[[GitHub]]}}
-* [[आर (प्रोग्रामिंग भाषा)]] परीक्षण के साथ
+* [[R ]] परीक्षण के साथ
-* [[स्काला (प्रोग्रामिंग भाषा)]]
+* [[स्काला]]
 * [[टीसीएल]]
 * विजुअल बेसिक .NET

v t e Software testing
The "box" approach	Black-box testing All-pairs testing Exploratory testing Fuzz testing Model-based testing Scenario testing Grey-box testing White-box testing API testing Mutation testing Static testing
Testing levels	Acceptance testing Integration testing System testing Unit testing
Testing types, techniques, and tactics	A/B testing Benchmark Compatibility testing Concolic testing Concurrent testing Conformance testing Continuous testing Destructive testing Development testing Dynamic program analysis Installation testing Regression testing Security testing Smoke testing (software) Software performance testing Symbolic execution Test automation Usability testing
See also	Graphical user interface testing Manual testing Orthogonal array testing Pair testing Soak testing Software reliability testing Stress testing Web testing

Anonymous

Search

इकाई परीक्षण: Difference between revisions

Namespaces

More

Page actions

Revision as of 15:48, 11 March 2023

Contents

इतिहास

विवरण

लाभ

सीमाएं और नुकसान

उदाहरण

निष्पादन योग्य विनिर्देशों के रूप में

अनुप्रयोग

चरम प्रोग्रामिंग

इकाई टेस्टिंग फ्रेमवर्क

भाषा-स्तरीय इकाई परीक्षण समर्थन

यह भी देखें

संदर्भ

अग्रिम पठन

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

इकाई परीक्षण: Difference between revisions

Revision as of 15:48, 11 March 2023

इतिहास

विवरण

लाभ

सीमाएं और नुकसान

उदाहरण

निष्पादन योग्य विनिर्देशों के रूप में

अनुप्रयोग

चरम प्रोग्रामिंग

इकाई टेस्टिंग फ्रेमवर्क

भाषा-स्तरीय इकाई परीक्षण समर्थन

यह भी देखें

संदर्भ

अग्रिम पठन

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories