इकाई परीक्षण

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

इतिहास

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

विवरण

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

उत्पन्न होने वाली समस्याओं को अलग करने के लिए, प्रत्येक परीक्षण मामले का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। विधि ठूंठ, नकली वस्तु ्स जैसे स्थानापन्न, नकली वस्तु#Mocks.2C नकली. 2C और स्टब्स, और परीक्षण हार्नेस का उपयोग अलगाव में एक मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।

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

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

लाभ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण

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

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

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

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

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

यूनिट टेस्टिंग फ्रेमवर्क

See also: List of unit testing frameworks

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

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

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

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

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

• कोबरा (प्रोग्रामिंग भाषा)
• डी (प्रोग्रामिंग भाषा)
• जंग (प्रोग्रामिंग भाषा)

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

• एपेक्स (प्रोग्रामिंग भाषा)
• क्रिस्टल (प्रोग्रामिंग भाषा)
• एरलांग (प्रोग्रामिंग भाषा)
• जाओ (प्रोग्रामिंग भाषा)
• जूलिया (प्रोग्रामिंग भाषा)
• लैब व्यू
• मतलब
• पायथन (प्रोग्रामिंग भाषा)
• रैकेट (प्रोग्रामिंग भाषा)
• रूबी (प्रोग्रामिंग भाषा)

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

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

• एबीएपी
• सी ++
• सी शार्प (प्रोग्रामिंग भाषा)|सी#
• क्लोजर
• अमृत (प्रोग्रामिंग भाषा)
• जावा (प्रोग्रामिंग भाषा)
• जावास्क्रिप्ट
• उद्देश्य सी
• पर्ल
• पीएचपी
• विंडोज पॉवरशेल

रेफरी>"पेस्टर फ्रेमवर्क". GitHub. Retrieved 28 January 2016.</ref>

• आर (प्रोग्रामिंग भाषा) परीक्षण के साथ
• स्काला (प्रोग्रामिंग भाषा)
• टीसीएल
• विजुअल बेसिक .NET
• Xojo के साथ XojoUnit

यह भी देखें

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

अग्रिम पठन

• 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)