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

From Vigyanwiki
No edit summary
No edit summary
 
(9 intermediate revisions by 6 users not shown)
Line 7: Line 7:


== इतिहास ==
== इतिहास ==
इकाई परीक्षण से पहले  [[कब्जा और फिर से परीक्षण परीक्षण|कैप्चर और रीप्ले परीक्षण]] टूल,आदर्श थे। 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>




Line 14: Line 14:




इकाई परीक्षण समान्यतया [[सॉफ्टवेयर डेवलपर]] द्वारा लिखित और चलाए जाने वाले [[स्वचालित परीक्षण]] होते हैं, अतएव यह सुनिश्चित किया जा सके कि किसी एप्लिकेशन का एक भाग अपने [[सॉफ्टवेर डिज़ाइन|सॉफ्टवेर प्रारूप]] को पूर्ण करता है और इच्छित व्यवहार करता है।<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="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" />


उत्पन्न होने वाली समस्याओं को पृथक करने के लिए, प्रत्येक परीक्षण स्थिति का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। [[विधि ठूंठ|मेथड स्टब्स,]], [[विधि ठूंठ|मॉक ऑब्जेक्ट्स,]]फेक और टेस्ट हार्नेस जैसे सब्स्टीट्यूट्स का उपयोग पृथक्करण में मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।।
उत्पन्न होने वाली समस्याओं को पृथक करने के लिए, प्रत्येक परीक्षण स्थिति का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। [[विधि ठूंठ|मेथड स्टब्स,]], [[विधि ठूंठ|मॉक ऑब्जेक्ट्स,]]फेक और टेस्ट हार्नेस जैसे सब्स्टीट्यूट्स का उपयोग पृथक्करण में मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।।
Line 29: Line 29:
इकाई परीक्षण [[विकास चक्र]] के प्रारंभिक समस्याओं का पता लगाता है।प्रोग्रामर के कार्यान्वयन में बग और इकाई के लिए विनिर्देश के दोष या अनुपस्थित हिस्से दोनों सम्मिलित हैं। परीक्षणों का एक संपूर्ण सेट लिखने की प्रक्रिया लेखक को इनपुट, आउटपुट और त्रुटि स्थितियों के माध्यम से सोचने के लिए मजबूर करती है, और इस प्रकार इकाई के वांछित व्यवहार को और अधिक स्पष्ट रूप से परिभाषित करती है। कोडिंग प्रारंभ होने से पहले बग को खोजने की लागत या जब कोड पहली बार लिखा जाता है,तो बग का पता लगाने, पहचानने और ठीक करने की लागत से अत्यधिक न्यूनतम होता है।अंतिम उपयोगकर्ताओं के लिए जारी किए गए कोड में भी बग सॉफ़्टवेयर के महंगी समस्याएँ उत्पन्न कर सकते हैं।<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> खराब लिखे जाने पर इकाई परीक्षण के लिए कोड असंभव या कठिन हो सकता है, इस प्रकार इकाई परीक्षण डेवलपर्स को उन्नति विधि से संरचना कार्यों और वस्तुओं के लिए मजबूर कर सकता है।


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


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


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


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


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


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


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


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


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


सॉफ्टवेयर परीक्षण एक मिश्रित समस्या है। उदाहरण के लिए, प्रत्येक बूलियन निर्णय कथन के लिए न्यूनतम से न्यूनतम दो परीक्षणों की आवश्यकता होती है: एक सत्य के परिणाम के सापेक्ष और एक गलत के परिणाम के सापेक्ष। परिणामस्वरूप, लिखे गए कोड की प्रत्येक पंक्ति के लिए, प्रोग्रामर को प्रायः टेस्ट कोड की 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>


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


यह सुनिश्चित करने के लिए एक स्थायी प्रक्रिया को लागू करना भी आवश्यक है कि परीक्षण न्यूनतम की विफलताओं की नियमित रूप से समीक्षा की जाती है और तुरंत संबोधित किया जाता है।<ref>{{cite web|last=daVeiga|first=Nada|author-link=Nada daVeiga| title=Change Code Without Fear: Utilize a regression safety net|date=2008-02-06| access-date=2008-02-08|url=http://www.ddj.com/development-tools/206105233}}</ref> यदि इस तरह की प्रक्रिया को लागू नहीं किया जाता है और टीम के वर्कफ़्लो में सम्मिलित हो जाता है, तो एप्लिकेशन इकाई टेस्ट सूट के सापेक्ष सिंक से बाहर हो जाएगा, झूठी सकारात्मकता बढ़ जाएगी और टेस्ट सूट की प्रभावशीलता न्यूनतम हो जाएगी।
यह सुनिश्चित करने के लिए एक स्थायी प्रक्रिया को लागू करना भी आवश्यक है कि परीक्षण न्यूनतम विफलताओं की नियमित रूप से समीक्षा की जाय और तुरंत संबोधित किया जाता है।<ref>{{cite web|last=daVeiga|first=Nada|author-link=Nada daVeiga| title=Change Code Without Fear: Utilize a regression safety net|date=2008-02-06| access-date=2008-02-08|url=http://www.ddj.com/development-tools/206105233}}</ref> यदि इस तरह की प्रक्रिया को प्रारंभ नहीं किया जाता है और टीम के वर्कफ़्लो में सम्मिलित हो जाता है, तो एप्लिकेशन इकाई टेस्ट सूट के सापेक्ष सिंक से बाहर हो जाएगा, झूठी सकारात्मकता बढ़ जाएगी और टेस्ट सूट की प्रभावशीलता न्यूनतम हो जाएगी।


इकाई परीक्षण एम्बेडेड प्रणाली सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक पृथक प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्ष संभव है।<ref>{{cite web|last=Kucharski|first=Marek|author-link=Marek Kucharski| title=अंतःस्थापित विकास के लिए इकाई परीक्षण को व्यावहारिक बनाना|date=2011-11-23| access-date=2020-07-20|url=https://www.electronicdesign.com/technologies/embedded-revolution/article/21794376/making-unit-testing-practical-for-embedded-development}}</ref>
इकाई परीक्षण एम्बेडेड प्रणाली सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक पृथक प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, और आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्ष संभव है।<ref>{{cite web|last=Kucharski|first=Marek|author-link=Marek Kucharski| title=अंतःस्थापित विकास के लिए इकाई परीक्षण को व्यावहारिक बनाना|date=2011-11-23| access-date=2020-07-20|url=https://www.electronicdesign.com/technologies/embedded-revolution/article/21794376/making-unit-testing-practical-for-embedded-development}}</ref>
इकाई परीक्षण सबसे आसान होते हैं जब किसी विधि में इनपुट पैरामीटर और कुछ आउटपुट होते हैं। इकाई परीक्षण बनाना उतना आसान नहीं है जब विधि का एक प्रमुख कार्य अनुप्रयोग के लिए किसी बाहरी चीज़ के सापेक्ष सहभागिता करना हो। उदाहरण के लिए, एक विधि जो डेटाबेस के सापेक्ष कार्य करेगी, उसे बनाने के लिए डेटाबेस इंटरैक्शन के मॉकअप की आवश्यकता हो सकती है, जो संभवतः वास्तविक डेटाबेस इंटरैक्शन के रूप में व्यापक नहीं होगा।<ref>http://wiki.c2.com/?UnitTestsAndDatabases {{Bare URL inline|date=August 2022}}</ref>
 
इकाई परीक्षण सबसे आसान होते हैं जब किसी विधि में कुछ इनपुट और आउटपुट पैरामीटर होते हैं। इकाई परीक्षण बनाना उतना आसान नहीं है जितना विधि का एक प्रमुख कार्य अनुप्रयोग के लिए किसी बाहरी चीज़ के सापेक्ष सहभागिता करना है। उदाहरण के लिए, एक विधि जो डेटाबेस के सापेक्ष कार्य करेगी, उसे बनाने के लिए डेटाबेस इंटरैक्शन के मॉकअप की आवश्यकता हो सकती है, जो संभवतः वास्तविक डेटाबेस इंटरैक्शन के रूप में व्यापक नहीं होगा।<ref>http://wiki.c2.com/?UnitTestsAndDatabases {{Bare URL inline|date=August 2022}}</ref>


== उदाहरण ==
== उदाहरण ==
Line 119: Line 120:


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


<syntaxhighlight lang="java">
<syntaxhighlight lang="java">
Line 135: Line 136:
== निष्पादन योग्य विनिर्देशों के रूप में ==
== निष्पादन योग्य विनिर्देशों के रूप में ==


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


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


== अनुप्रयोग ==
== अनुप्रयोग ==


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


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


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


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


इमर्जेंट प्रारूप की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि [[आकस्मिक डिजाइन|आकस्मिक प्रारूप]] रिफैक्टरिंग पर अत्यधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।<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>
Line 160: Line 159:
इकाई परीक्षण फ्रेमवर्क प्रायः तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे इकाई परीक्षण फ्रेमवर्क की सूची के लिए विकसित किए जाने के उपरांत इकाई परीक्षण की प्रक्रिया को आसान बनाने में सहायता करते हैं।
इकाई परीक्षण फ्रेमवर्क प्रायः तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे इकाई परीक्षण फ्रेमवर्क की सूची के लिए विकसित किए जाने के उपरांत इकाई परीक्षण की प्रक्रिया को आसान बनाने में सहायता करते हैं।


क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना इकाई परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए [[अभिकथन (सॉफ्टवेयर विकास)]], अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना कदाचित ही कोई नहीं होने से श्रेष्ठतर है, जबकि एक बार एक ढांचा होने के उपरांत, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।<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}}
{{colbegin|colwidth=20em}}
* [[कोबरा]]
* [[कोबरा]]
Line 172: Line 171:
{{colend}}
{{colend}}


मानक इकाई परीक्षण ढांचे के समर्थन वाली भाषाओं में सम्मिलित हैं:
मानक इकाई परीक्षण ढांचे को समर्थन करने वाली भाषाओं में सम्मिलित हैं:
{{colbegin|colwidth=20em}}
{{colbegin|colwidth=20em}}
* एपेक्स
* एपेक्स
Line 214: Line 213:
* [[लक्षण वर्णन परीक्षण]]
* [[लक्षण वर्णन परीक्षण]]
* [[घटक-आधारित उपयोगिता परीक्षण]]
* [[घटक-आधारित उपयोगिता परीक्षण]]
* [[डिजाइन भविष्यवाणी करता है]]
* [[प्रारूप प्रेडीकेटस]]
* अनुबंध द्वारा डिजाइन
* अनुबंध द्वारा प्रारूप
* चरम कार्यक्रम
* एक्सट्रीम प्रोग्रामिंग
* [[क्रियात्मक परीक्षण]]
* [[क्रियात्मक परीक्षण]]
* एकीकरण जांच
* एकीकरण परीक्षण
* यूनिट टेस्टिंग फ्रेमवर्क की सूची
* यूनिट टेस्टिंग फ्रेमवर्क की सूची
* प्रतिगमन परीक्षण
* प्रतिगमन परीक्षण
* [[सॉफ्टवेयर पुरातत्व]]
* [[सॉफ्टवेयर पुरातत्व]]
* सॉफ़्टवेयर परीक्षण
* सॉफ़्टवेयर परीक्षण
* परीक्षण मामला
* परीक्षण परिस्थिति
* परीक्षण संचालित विकास
* परीक्षण संचालित विकास
* xUnit - यूनिट टेस्टिंग फ्रेमवर्क का परिवार।
* xUnit - यूनिट टेस्टिंग फ्रेमवर्क का परिवार।
Line 243: Line 242:
* [http://c2.com/cgi/wiki?TestDrivenDevelopment Test Driven Development (Ward Cunningham's Wiki)]
* [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]]

Latest revision as of 12:37, 1 November 2023

Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries
Outlines

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


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

See also: यूनिट टेस्टिंग फ्रेमवर्क की सूची

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

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

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

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

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

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

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

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

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

यह भी देखें

संदर्भ

  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)
  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. ↑ daVeiga, 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. ↑ http://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.
  26. ↑ Welsh, Noel; Culpepper, Ryan. "रैकयूनिट: यूनिट परीक्षण". PLT Design Inc. Retrieved 26 February 2019.
  27. ↑ Welsh, Noel; Culpepper, Ryan. "रैकेट यूनिट परीक्षण पैकेज रैकेट मुख्य वितरण का हिस्सा है". PLT Design Inc. Retrieved 26 February 2019.
  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)


अग्रिम पठन

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


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=इकाई_परीक्षण&oldid=272065’