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

Latest revision as of 12:37, 1 November 2023

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

इतिहास

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

विवरण

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

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

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

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

लाभ

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

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

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

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

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

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

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

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

सीमाएं और त्रुटि

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

इकाई परीक्षणों का एक विस्तृत पदानुक्रम एकीकरण परीक्षण के समान नहीं है। परिधीय इकाइयों के सापेक्ष एकीकरण को एकीकरण परीक्षणों में सम्मिलित किया जाना चाहिए, परंतु इकाई परीक्षणों में नहीं। एकीकरण परीक्षण समान्यतयया अभी भी मैन्युअल रूप से मानव परीक्षण पर अत्यधिक निर्भर करता है; उच्च-स्तरीय या वैश्विक-दायरे के परीक्षण को स्वचालित करना कठिन हो सकता है, जैसे मैन्युअल परीक्षण प्रायः तीव्र और सस्ता दिखाई देता है।

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

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

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

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

इकाई परीक्षण एम्बेडेड प्रणाली सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक पृथक प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, और आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्ष संभव है।^[16]

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

उदाहरण

यहाँ जावा में परीक्षण स्थिति का एक सेट है जो कार्यान्वयन के कई तत्वों को निर्दिष्ट करता है। सबसे पहले, एडर नामक एक इंटरफ़ेस होना चाहिए, और एक शून्य-तर्क निर्माता के सापेक्ष एक कार्यान्वयन क्लास जिसे 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;
    }
}

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

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

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

अनुप्रयोग

एक्सट्रीम प्रोग्रामिंग

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

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

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

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

इमर्जेंट प्रारूप की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि आकस्मिक प्रारूप रिफैक्टरिंग पर अत्यधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।^[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 और स्टब्स, और परीक्षण हार्नेस का उपयोग अलगाव में एक मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।
-विकास के दौरान, एक सॉफ्टवेयर डेवलपर यूनिट की शुद्धता को सत्यापित करने के लिए परीक्षण में मापदंड, या परिणाम जो अच्छे माने जाते हैं, को कोड कर सकता है। टेस्ट केस एक्जीक्यूशन के दौरान, फ्रेमवर्क [[कंप्यूटर डेटा लॉगिंग]] टेस्ट जो किसी भी मानदंड को विफल करते हैं और उन्हें सारांश में रिपोर्ट करते हैं। इसके लिए, सबसे अधिक इस्तेमाल किया जाने वाला तरीका टेस्ट-फंक्शन-अपेक्षित मूल्य है।
-[[पैरामीटरयुक्त परीक्षण]]ों का उपयोग करके यूनिट परीक्षणों को लिखना और बनाए रखना तेजी से बनाया जा सकता है। ये विभिन्न इनपुट सेटों के साथ एक परीक्षण को कई बार निष्पादित करने की अनुमति देते हैं, इस प्रकार परीक्षण कोड दोहराव को कम करते हैं। पारंपरिक इकाई परीक्षणों के विपरीत, जो आमतौर पर बंद तरीके हैं और अपरिवर्तनीय स्थितियों का परीक्षण करते हैं, पैरामीटरयुक्त परीक्षण पैरामीटर के किसी भी सेट को लेते हैं। 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="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" />
+उत्पन्न होने वाली समस्याओं को पृथक करने के लिए, प्रत्येक परीक्षण स्थिति का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। [[विधि ठूंठ|मेथड स्टब्स,]], [[विधि ठूंठ|मॉक ऑब्जेक्ट्स,]]फेक और टेस्ट हार्नेस जैसे सब्स्टीट्यूट्स का उपयोग पृथक्करण में मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।।
+विकास के दौरान, एक सॉफ्टवेयर डेवलपर को इकाई की शुद्धता को सत्यापित करने के लिए परीक्षण में मापदंड, या परिणाम जो सही माने जाते हैं, उसको कोड कर सकता है। टेस्ट केस एक्जीक्यूशन के दौरान, फ्रेमवर्क [[कंप्यूटर डेटा लॉगिंग]] टेस्ट जो प्रत्येक मानदंड को विफल कर सकते हैं तथा फ्रेमवर्क [[कंप्यूटर डेटा लॉगिंग]] को संक्षेप में रिपोर्ट करते हैं।टेस्ट-फंक्शन-एक्सपेक्टेड वैल्यू अधिकतम उपयोग किया जाने वाला विधि है।
+इकाई परीक्षणों को लिखना और बनाए रखना [[पैरामीटरयुक्त परीक्षण]] का उपयोग द्वारा तीव्रता से बनाया जा सकता है। यह विभिन्न इनपुट सेटों के सापेक्ष एक परीक्षण को कई बार निष्पादित करने की अनुमति देता हैं, इस प्रकार परीक्षण कोड दोहराव को न्यूनतम करते हैं। पारंपरिक इकाई परीक्षणों के विपरीत, जो समान्यतया बंद विधि हैं तथा अपरिवर्तनीय स्थितियों का परीक्षण करता हैं, पैरामीटरयुक्त परीक्षण के प्रत्येक पैरामीटर सेट कर लेते हैं। पैरामीटरयुक्त परीक्षण [[TestNG|टेस्टNG]] , JUnit और इसके .नेट काउंटरपार्ट, [[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=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=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=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>http://wiki.c2.com/?UnitTestsAndDatabases {{Bare URL inline|date=August 2022}}</ref>{{better source needed|date=February 2019}}
+इकाई परीक्षण एम्बेडेड प्रणाली सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक पृथक प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, और आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्ष संभव है।<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>
 == उदाहरण ==
-यहाँ जावा (प्रोग्रामिंग भाषा) में परीक्षण मामलों का एक सेट है जो कार्यान्वयन के कई तत्वों को निर्दिष्ट करता है। सबसे पहले, एडर नामक एक इंटरफ़ेस होना चाहिए, और एक शून्य-तर्क निर्माता के साथ एक कार्यान्वयन वर्ग जिसे AdderImpl कहा जाता है। यह [[अभिकथन (कंप्यूटिंग)]] पर जाता है कि योजक इंटरफ़ेस में दो पूर्णांक मापदंडों के साथ ऐड नामक एक विधि होनी चाहिए, जो एक और पूर्णांक लौटाती है। यह कई परीक्षण विधियों पर मूल्यों की एक छोटी श्रृंखला के लिए इस पद्धति के व्यवहार को भी निर्दिष्ट करता है।
+यहाँ जावा  में परीक्षण स्थिति का एक सेट है जो कार्यान्वयन के कई तत्वों को निर्दिष्ट करता है। सबसे पहले, एडर नामक एक इंटरफ़ेस होना चाहिए, और एक शून्य-तर्क निर्माता के सापेक्ष एक कार्यान्वयन क्लास जिसे AdderImpl कहा जाता है। यह [[अभिकथन (कंप्यूटिंग)]] पर जाता है कि योजक इंटरफ़ेस में दो पूर्णांक मापदंडों के सापेक्ष ऐड नामक एक विधि होनी चाहिए, जो एक और पूर्णांक लौटाती है। यह कई परीक्षण विधियों पर मूल्यों की एक छोटी श्रृंखला के लिए इस पद्धति के व्यवहार को भी निर्दिष्ट करता है।
 <syntaxhighlight lang="java">
@@ Line 117: / Line 120: @@
 </syntaxhighlight>
-इस मामले में इकाई परीक्षण, पहले लिखे जाने के बाद, एक वांछित समाधान के रूप और व्यवहार को निर्दिष्ट करने वाले एक डिज़ाइन दस्तावेज़ के रूप में कार्य करता है, लेकिन कार्यान्वयन विवरण नहीं, जो प्रोग्रामर के लिए छोड़ दिया जाता है। सबसे आसान काम करने का पालन करना जो संभवत: अभ्यास का काम कर सकता है, सबसे आसान समाधान जो टेस्ट पास करेगा, नीचे दिखाया गया है।
+इस स्थिति में इकाई परीक्षण, पहले लिखे जाने के उपरांत, एक वांछित समाधान के रूप और व्यवहार को निर्दिष्ट करने वाला एक प्रारूप दस्तावेज़ के रूप में कार्य करता है, परंतु कार्यान्वयन विवरण नहीं, जो प्रोग्रामर के लिए छोड़ दिया जाता है।सबसे आसान काम करें जो संभवतः काम कर सकता है, अभ्यास के उपरांत,सबसे आसान समाधान जो टेस्ट पास करेगा। नीचे दर्शाया गया है :-
 <syntaxhighlight lang="java">
@@ Line 132: / Line 135: @@
 == निष्पादन योग्य विनिर्देशों के रूप में ==
-{{unreferenced section|date=September 2019}}
-डिज़ाइन विनिर्देश के रूप में यूनिट-टेस्ट का उपयोग करने से अन्य डिज़ाइन विधियों पर एक महत्वपूर्ण लाभ होता है: डिज़ाइन दस्तावेज़ (यूनिट-परीक्षण स्वयं) का उपयोग कार्यान्वयन को सत्यापित करने के लिए किया जा सकता है। जब तक डेवलपर डिजाइन के अनुसार समाधान लागू नहीं करता तब तक परीक्षण कभी पास नहीं होंगे।
-यूनिट परीक्षण में [[एकीकृत मॉडलिंग भाषा]] आरेख जैसे डायग्रामेटिक विनिर्देश की कुछ पहुंच की कमी है, लेकिन वे स्वचालित टूल का उपयोग करके यूनिट परीक्षण से उत्पन्न हो सकते हैं। अधिकांश आधुनिक भाषाओं में नि: शुल्क उपकरण होते हैं (आमतौर पर एकीकृत विकास परिवेशों के विस्तार के रूप में उपलब्ध होते हैं)। नि: शुल्क उपकरण, जैसे कि xUnit ढांचे पर आधारित, मानव उपभोग के लिए एक दृश्य के चित्रमय प्रतिपादन के लिए किसी अन्य प्रणाली को आउटसोर्स करते हैं।
+प्रारूप विनिर्देश के रूप में इकाई-टेस्ट का उपयोग करने से अन्य प्रारूप विधियों पर एक महत्वपूर्ण लाभ होता है: प्रारूप दस्तावेज़ का उपयोग कार्यान्वयन को सत्यापित करने के लिए किया जा सकता है। जब तक डेवलपर प्रारूप के अनुसार समाधान लागू नहीं करता तब तक परीक्षण कभी पास नहीं हो सकते हैं।
+इकाई परीक्षण में [[एकीकृत मॉडलिंग भाषा|एकीकृत मॉडलिंग भाषा(UML)]] आरेख जैसे डायग्रामेटिक विनिर्देश की कुछ पहुंच की न्यूनता होती है, परंतु स्वचालित उपकरणों का उपयोग करके इकाई परीक्षण को उत्पन्न कर सकते हैं। अधिकांश आधुनिक भाषाओं में नि: शुल्क उपकरण होते हैं। नि: शुल्क उपकरण, जैसे कि xUnit फ्रेमवर्क, मानव उपभोग के लिए एक दृश्य के ग्राफिकल रेंडरिंग के लिए किसी अन्य प्रणाली के आउटसोर्स का उपयोग करते हैं।
 == अनुप्रयोग ==
-=== चरम प्रोग्रामिंग ===
+=== एक्सट्रीम प्रोग्रामिंग ===
-यूनिट टेस्टिंग एक्सट्रीम प्रोग्रामिंग की आधारशिला है[[इकाई परीक्षण ढांचे की सूची]] की एक स्वचालित सूची पर निर्भर करती है। यह स्वचालित इकाई परीक्षण ढांचा या तो तृतीय पक्ष हो सकता है, उदाहरण के लिए, xUnit, या विकास समूह के भीतर बनाया गया।
+इकाई परीक्षण एक्सट्रीम प्रोग्रामिंग की आधारशिला है [[इकाई परीक्षण ढांचे की सूची|इकाई परीक्षण फ्रेमवर्क]] एक स्वचालित सूची पर निर्भर करता है। यह स्वचालित इकाई परीक्षण फ्रेमवर्क तृतीय पक्ष हो सकता है, उदाहरण के लिए, xUnit, या विकास समूह के अंतर्गत बनाया गया हो।
-चरम प्रोग्रामिंग परीक्षण-संचालित विकास के लिए इकाई परीक्षणों के निर्माण का उपयोग करती है। डेवलपर एक इकाई परीक्षण लिखता है जो सॉफ़्टवेयर आवश्यकता या दोष को उजागर करता है। यह परीक्षण विफल हो जाएगा क्योंकि या तो आवश्यकता अभी तक लागू नहीं हुई है, या क्योंकि यह जानबूझकर मौजूदा कोड में एक दोष को उजागर करता है। फिर, डेवलपर परीक्षण करने के लिए सबसे सरल कोड लिखता है, अन्य परीक्षणों के साथ, पास करता है।
+एक्सट्रीम प्रोग्रामिंग परीक्षण-संचालित विकास के लिए इकाई परीक्षणों के निर्माण का उपयोग करती है। डेवलपर एक इकाई परीक्षण लिखता है जो सॉफ़्टवेयर के आवश्यकता या दोष को उजागर करता है। यह परीक्षण विफल हो सकता है क्योंकि अभी तक आवश्यकताओ कों प्रारंभ नहीं किया गया है, या यह अभिप्रायपूर्वक मौजूदा कोड में एक त्रुटी को उजागर करता है। पुनः, डेवलपर परीक्षण करने के लिए सबसे सरल कोड लिखता है, अन्य परीक्षणों के सापेक्ष,पास करता है।
-सिस्टम में अधिकांश कोड यूनिट टेस्टेड होते हैं, लेकिन जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, लेकिन यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।{{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}}
+{{See also|यूनिट टेस्टिंग फ्रेमवर्क की सूची}}
-यूनिट टेस्टिंग फ्रेमवर्क अक्सर तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे यूनिट टेस्टिंग फ्रेमवर्क की सूची के लिए विकसित किए जाने के बाद यूनिट टेस्टिंग की प्रक्रिया को आसान बनाने में मदद करते हैं।
+इकाई परीक्षण फ्रेमवर्क प्रायः तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे इकाई परीक्षण फ्रेमवर्क की सूची के लिए विकसित किए जाने के उपरांत इकाई परीक्षण की प्रक्रिया को आसान बनाने में सहायता करते हैं।
-क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना यूनिट परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए [[अभिकथन (सॉफ्टवेयर विकास)]], अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना शायद ही कोई नहीं होने से बेहतर है, जबकि एक बार एक ढांचा होने के बाद, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।<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
@@ Line 209: / Line 213: @@
 * [[लक्षण वर्णन परीक्षण]]
 * [[घटक-आधारित उपयोगिता परीक्षण]]
-* [[डिजाइन भविष्यवाणी करता है]]
+* [[प्रारूप प्रेडीकेटस]]
-* अनुबंध द्वारा डिजाइन
+* अनुबंध द्वारा प्रारूप
-* चरम कार्यक्रम
+* एक्सट्रीम प्रोग्रामिंग
 * [[क्रियात्मक परीक्षण]]
-* एकीकरण जांच
+* एकीकरण परीक्षण
 * यूनिट टेस्टिंग फ्रेमवर्क की सूची
 * प्रतिगमन परीक्षण
 * [[सॉफ्टवेयर पुरातत्व]]
 * सॉफ़्टवेयर परीक्षण
-* परीक्षण मामला
+* परीक्षण परिस्थिति
 * परीक्षण संचालित विकास
 * xUnit - यूनिट टेस्टिंग फ्रेमवर्क का परिवार।
@@ Line 238: / Line 242: @@
 * [http://c2.com/cgi/wiki?TestDrivenDevelopment Test Driven Development (Ward Cunningham's Wiki)]
-{{Software testing}}
+[[Category:All articles with bare URLs for citations]]
+[[Category:Articles with bare URLs for citations from August 2022]]
-{{DEFAULTSORT:Unit Testing}}[[Category: यूनिट टेस्टिंग| यूनिट टेस्टिंग]] [[Category: चरम कार्यक्रम]] [[Category: जावा कोड उदाहरण के साथ लेख]] [[Category: सॉफ्टवेयर विकास में प्रयुक्त उपकरणों के प्रकार]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Unit Testing]]
+[[Category:Articles with invalid date parameter in template]]
+[[Category:CS1 errors]]
+[[Category:Collapse templates|Unit Testing]]
-[[Category: Machine Translated Page]]
+[[Category:Created On 02/03/2023|Unit Testing]]
-[[Category:Created On 02/03/2023]]
+[[Category:Lua-based templates]]
+[[Category:Machine Translated Page|Unit Testing]]
+[[Category:Multi-column templates]]
+[[Category:Navigational boxes| ]]
+[[Category:Pages using div col with small parameter]]
+[[Category:Pages with script errors]]
+[[Category:Short description with empty Wikidata description]]
+[[Category:Templates Translated in Hindi]]
+[[Category:Templates Vigyan Ready]]
+[[Category:Templates that add a tracking category]]
+[[Category:Templates that generate short descriptions]]
+[[Category:Templates using TemplateData]]
+[[Category:Templates using under-protected Lua modules]]
+[[Category:Wikipedia fully protected templates|Div col]]

Anonymous

Search

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

Namespaces

More

Page actions

Latest revision as of 12:37, 1 November 2023

Contents

इतिहास

विवरण

लाभ

सीमाएं और त्रुटि

उदाहरण

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

अनुप्रयोग

एक्सट्रीम प्रोग्रामिंग

इकाई परीक्षण फ्रेमवर्क

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

यह भी देखें

संदर्भ

अग्रिम पठन

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

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

Latest revision as of 12:37, 1 November 2023

इतिहास

विवरण

लाभ

सीमाएं और त्रुटि

उदाहरण

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

अनुप्रयोग

एक्सट्रीम प्रोग्रामिंग

इकाई परीक्षण फ्रेमवर्क

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

यह भी देखें

संदर्भ

अग्रिम पठन

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Hidden categories