इकाई परीक्षण: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
{{Software development process|Core activities}} | {{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> | ||
== इतिहास == | == इतिहास == | ||
इकाई | इकाई परीक्षण से पहले [[कब्जा और फिर से परीक्षण परीक्षण|कैप्चर और रीप्ले परीक्षण]] टूल आदर्श थे। 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 13: | Line 13: | ||
इकाई परीक्षण आमतौर पर [[सॉफ्टवेयर डेवलपर]] द्वारा लिखित और चलाए जाने वाले [[स्वचालित परीक्षण]] होते हैं यद्यपि यह सुनिश्चित किया जा सके कि किसी एप्लिकेशन का एक भाग | |||
इकाई परीक्षण आमतौर पर [[सॉफ्टवेयर डेवलपर]] द्वारा लिखित और चलाए जाने वाले [[स्वचालित परीक्षण]] होते हैं यद्यपि यह सुनिश्चित किया जा सके कि किसी एप्लिकेशन का एक भाग अपने [[सॉफ्टवेर डिज़ाइन]] को पूर्ण करता है और इच्छित व्यवहार करता है।<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 141: | Line 142: | ||
=== चरम प्रोग्रामिंग === | === चरम प्रोग्रामिंग === | ||
इकाई | इकाई परीक्षण एक्सट्रीम प्रोग्रामिंग की आधारशिला है[[इकाई परीक्षण ढांचे की सूची]] की एक स्वचालित सूची पर निर्भर करती है। यह स्वचालित इकाई परीक्षण ढांचा या तो तृतीय पक्ष हो सकता है, उदाहरण के लिए, xUnit, या विकास समूह के भीतर बनाया गया। | ||
चरम प्रोग्रामिंग परीक्षण-संचालित विकास के लिए इकाई परीक्षणों के निर्माण का उपयोग करती है। डेवलपर एक इकाई परीक्षण लिखता है जो सॉफ़्टवेयर आवश्यकता या दोष को उजागर करता है। यह परीक्षण विफल हो जाएगा क्योंकि या तो आवश्यकता अभी तक लागू नहीं हुई है, या क्योंकि यह जानबूझकर मौजूदा कोड में एक दोष को उजागर करता है। फिर, डेवलपर परीक्षण करने के लिए सबसे सरल कोड लिखता है, अन्य परीक्षणों के साथ, पास करता है। | चरम प्रोग्रामिंग परीक्षण-संचालित विकास के लिए इकाई परीक्षणों के निर्माण का उपयोग करती है। डेवलपर एक इकाई परीक्षण लिखता है जो सॉफ़्टवेयर आवश्यकता या दोष को उजागर करता है। यह परीक्षण विफल हो जाएगा क्योंकि या तो आवश्यकता अभी तक लागू नहीं हुई है, या क्योंकि यह जानबूझकर मौजूदा कोड में एक दोष को उजागर करता है। फिर, डेवलपर परीक्षण करने के लिए सबसे सरल कोड लिखता है, अन्य परीक्षणों के साथ, पास करता है। | ||
| Line 147: | Line 148: | ||
सिस्टम में अधिकांश कोड इकाई टेस्टेड होते हैं, परंतु जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, परंतु यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।{{Citation needed|date=November 2008}} एक्सट्रीम प्रोग्रामिंग केवल यह पहचानती है कि परीक्षण शायद ही कभी संपूर्ण होता है (क्योंकि यह आर्थिक रूप से व्यवहार्य होने के लिए प्रायः बहुत महंगा और समय लेने वाला होता है) और सीमित संसाधनों को प्रभावी ढंग से केंद्रित करने के तरीके पर मार्गदर्शन प्रदान करता है। | सिस्टम में अधिकांश कोड इकाई टेस्टेड होते हैं, परंतु जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, परंतु यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।{{Citation needed|date=November 2008}} एक्सट्रीम प्रोग्रामिंग केवल यह पहचानती है कि परीक्षण शायद ही कभी संपूर्ण होता है (क्योंकि यह आर्थिक रूप से व्यवहार्य होने के लिए प्रायः बहुत महंगा और समय लेने वाला होता है) और सीमित संसाधनों को प्रभावी ढंग से केंद्रित करने के तरीके पर मार्गदर्शन प्रदान करता है। | ||
महत्वपूर्ण रूप से, परीक्षण कोड को प्रथम श्रेणी का प्रोजेक्ट आर्टिफैक्ट माना जाता है जिसमें इसे कार्यान्वयन कोड के समान गुणवत्ता पर बनाए रखा जाता है, जिसमें सभी दोहराव हटा दिए जाते हैं। डेवलपर्स इकाई | महत्वपूर्ण रूप से, परीक्षण कोड को प्रथम श्रेणी का प्रोजेक्ट आर्टिफैक्ट माना जाता है जिसमें इसे कार्यान्वयन कोड के समान गुणवत्ता पर बनाए रखा जाता है, जिसमें सभी दोहराव हटा दिए जाते हैं। डेवलपर्स इकाई परीक्षण कोड को कोड रिपॉजिटरी में उस कोड के सापेक्षजारी करते हैं जो वह परीक्षण करता है। एक्सट्रीम प्रोग्रामिंग का पूर्ण इकाई परीक्षण उपरोक्त लाभों की अनुमति देता है, जैसे कि सरल और अधिक विश्वसनीय कोड विकास और रीफैक्टरिंग, सरलीकृत कोड एकीकरण, सटीक प्रलेखन और अधिक मॉड्यूलर डिज़ाइन। ये इकाई परीक्षण भी प्रतिगमन परीक्षण के रूप में लगातार चलाए जाते हैं। | ||
इमर्जेंट डिज़ाइन की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि [[आकस्मिक डिजाइन]] रिफैक्टरिंग पर बहुत अधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।<ref>{{cite web |url=http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |title=फुर्तीली उभरती डिजाइन|publisher=Agile Sherpa |date=2010-08-03 |access-date=2012-05-08 |url-status=dead |archive-url=https://web.archive.org/web/20120322143534/http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |archive-date=22 March 2012}}</ref> | इमर्जेंट डिज़ाइन की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि [[आकस्मिक डिजाइन]] रिफैक्टरिंग पर बहुत अधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।<ref>{{cite web |url=http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |title=फुर्तीली उभरती डिजाइन|publisher=Agile Sherpa |date=2010-08-03 |access-date=2012-05-08 |url-status=dead |archive-url=https://web.archive.org/web/20120322143534/http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ |archive-date=22 March 2012}}</ref> | ||
=== इकाई | === इकाई परीक्षण फ्रेमवर्क === | ||
{{See also|List of unit testing frameworks}} | {{See also|List of unit testing frameworks}} | ||
इकाई | इकाई परीक्षण फ्रेमवर्क प्रायः तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे इकाई परीक्षण फ्रेमवर्क की सूची के लिए विकसित किए जाने के बाद इकाई परीक्षण की प्रक्रिया को आसान बनाने में मदद करते हैं। | ||
क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना इकाई परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए [[अभिकथन (सॉफ्टवेयर विकास)]], अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना शायद ही कोई नहीं होने से बेहतर है, जबकि एक बार एक ढांचा होने के बाद, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।<ref>{{cite web|url=http://www.bullseye.com/coverage.html|access-date=24 March 2009|title=मध्यवर्ती कवरेज लक्ष्य|author=Bullseye Testing Technology|date=2006–2008}}</ref> कुछ रूपरेखाओं में कई उन्नत इकाई परीक्षण सुविधाएँ गायब हैं या उन्हें हाथ से कोडित किया जाना चाहिए। | क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना इकाई परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए [[अभिकथन (सॉफ्टवेयर विकास)]], अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना शायद ही कोई नहीं होने से बेहतर है, जबकि एक बार एक ढांचा होने के बाद, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।<ref>{{cite web|url=http://www.bullseye.com/coverage.html|access-date=24 March 2009|title=मध्यवर्ती कवरेज लक्ष्य|author=Bullseye Testing Technology|date=2006–2008}}</ref> कुछ रूपरेखाओं में कई उन्नत इकाई परीक्षण सुविधाएँ गायब हैं या उन्हें हाथ से कोडित किया जाना चाहिए। | ||
=== भाषा-स्तरीय इकाई परीक्षण समर्थन === | === भाषा-स्तरीय इकाई परीक्षण समर्थन === | ||
कुछ प्रोग्रामिंग लैंग्वेज सीधे इकाई | कुछ प्रोग्रामिंग लैंग्वेज सीधे इकाई परीक्षण को सपोर्ट करती हैं। उनका व्याकरण पुस्तकालय आयात किए बिना इकाई परीक्षणों की प्रत्यक्ष घोषणा की अनुमति देता है । इसके अतिरिक्त, इकाई परीक्षणों की बूलियन स्थितियों को उसी सिंटैक्स में व्यक्त किया जा सकता है जैसे गैर-इकाई टेस्ट कोड में उपयोग किए जाने वाले बूलियन एक्सप्रेशन, जैसे कि किसके लिए उपयोग किया जाता है {{code| lang = java |if}} और {{code| lang = java |while}} कथन। | ||
अंतर्निहित इकाई परीक्षण समर्थन वाली भाषाओं में सम्मिलित हैं: | अंतर्निहित इकाई परीक्षण समर्थन वाली भाषाओं में सम्मिलित हैं: | ||
| Line 184: | Line 185: | ||
{{colend}} | {{colend}} | ||
कुछ भाषाओं में बिल्ट-इन इकाई- | कुछ भाषाओं में बिल्ट-इन इकाई-परीक्षण सपोर्ट नहीं करता है, परंतु इकाई परीक्षण लाइब्रेरी या फ्रेमवर्क स्थापित हैं। इन भाषाओं में सम्मिलित हैं: | ||
{{colbegin|colwidth=20em}} | {{colbegin|colwidth=20em}} | ||
* [[एबीएपी]] | * [[एबीएपी]] | ||
Revision as of 21:45, 12 March 2023
| Part of a series on |
| Software development |
|---|
कंप्यूटर प्रोग्रामिंग में, इकाई परीक्षण एक सॉफ्टवेयर परीक्षण विधि है जिसके द्वारा स्रोत कोड की भिन्न -भिन्न इकाइयां या कंप्यूटर प्रोग्राम मॉड्यूलर प्रोग्रामिंग के साथ-साथ संबंधित नियंत्रण डेटा, उपयोग प्रक्रिया , और संचालन प्रक्रियाओं का परीक्षण किया जाता है - यह निर्धारित करने के लिए परीक्षण किया जाता है कि क्या वे उपयोग के योग्य हैं।[1]
इतिहास
इकाई परीक्षण से पहले कैप्चर और रीप्ले परीक्षण टूल आदर्श थे। 1997 में, केंट बेक और एरिक गामा ने JUnit को विकसित और प्रारंभ किया, एक इकाई टेस्ट फ्रेमवर्क जो जावा डेवलपर्स के सापेक्ष लोकप्रिय हुआ।[2] गूगल ने 2005-2006 के आसपास स्वचालित परीक्षण को अपनाया।[3]
विवरण
इकाई परीक्षण आमतौर पर सॉफ्टवेयर डेवलपर द्वारा लिखित और चलाए जाने वाले स्वचालित परीक्षण होते हैं यद्यपि यह सुनिश्चित किया जा सके कि किसी एप्लिकेशन का एक भाग अपने सॉफ्टवेर डिज़ाइन को पूर्ण करता है और इच्छित व्यवहार करता है।[4] प्रक्रियात्मक प्रोग्रामिंग में, एक इकाई एक संपूर्ण मॉड्यूल हो सकती है, परंतु यह आमतौर पर एक व्यक्तिगत कार्य या प्रक्रिया है। वस्तु-उन्मुख प्रोग्रामिंग में, एक इकाई प्रायः एक संपूर्ण इंटरफ़ेस होती है, जैसे कि एक वर्ग या एक व्यक्तिगत विधि।[5] सबसे छोटी परीक्षण योग्य इकाइयों के लिए पहले परीक्षण लिखकर, फिर उन दोनों के मध्य मिश्रित व्यवहार, जटिल अनुप्रयोगों के लिए व्यापक परीक्षण तैयार कर सकते हैं।[4]
उत्पन्न होने वाली समस्याओं को अलग करने के लिए, प्रत्येक परीक्षण घटना का स्वतंत्र रूप से परीक्षण किया जाना चाहिए। मेथड स्टब्स,, मॉक ऑब्जेक्ट्स,फेक और टेस्ट हार्नेस जैसे सब्स्टीट्यूट्स का उपयोग अलगाव में मॉड्यूल के परीक्षण में सहायता के लिए किया जा सकता है।।
विकास के दौरान, एक सॉफ्टवेयर डेवलपर इकाई की शुद्धता को सत्यापित करने के लिए परीक्षण में मापदंड, या परिणाम जो अच्छे माने जाते हैं, को कोड कर सकता है। टेस्ट केस एक्जीक्यूशन के दौरान, फ्रेमवर्क कंप्यूटर डेटा लॉगिंग टेस्ट जो किसी भी मानदंड को विफल करते हैं और उन्हें सारांश में रिपोर्ट करते हैं। इसके लिए, सबसे अधिक उपयोग किया जाने वाला विधि टेस्ट-फंक्शन-अपेक्षित मूल्य है।
पैरामीटरयुक्त परीक्षण का उपयोग करके इकाई परीक्षणों को लिखना और बनाए रखना तेजी से बनाया जा सकता है। ये विभिन्न इनपुट सेटों के सापेक्ष एक परीक्षण को कई बार निष्पादित करने की अनुमति देते हैं, इस प्रकार परीक्षण कोड दोहराव को न्यूनतम करते हैं। पारंपरिक इकाई परीक्षणों के विपरीत, जो आमतौर पर बंद विधि हैं और अपरिवर्तनीय स्थितियों का परीक्षण करते हैं, पैरामीटरयुक्त परीक्षण पैरामीटर के किसी भी सेट को लेते हैं। Parameterized परीक्षण TestNG, JUnit और इसके .Net समकक्ष, XUnit द्वारा समर्थित हैं। इकाई परीक्षणों के लिए उपयुक्त पैरामीटर मैन्युअल रूप से आपूर्ति किए जा सकते हैं या कुछ घटनाओं में स्वचालित रूप से परीक्षण ढांचे द्वारा उत्पन्न होते हैं। हाल के वर्षों में अधिक शक्तिशाली (इकाई) परीक्षण लिखने, सिद्धांतों की अवधारणा का लाभ उठाने, समान चरणों को निष्पादित करने वाले परीक्षण मामलों के लिए समर्थन जोड़ा गया था, परंतु रनटाइम पर उत्पन्न परीक्षण डेटा का उपयोग करते हुए, नियमित पैरामीटरयुक्त परीक्षणों के विपरीत, जो इनपुट सेट के सापेक्ष समान निष्पादन चरणों का उपयोग करते हैं जो पूर्व निर्धारित हैं।[6][7][8]
लाभ
इकाई परीक्षण का लक्ष्य कार्यक्रम के प्रत्येक भाग को अलग करना है और यह दिखाना है कि भिन्न -भिन्न भाग सही हैं।[1]एक इकाई परीक्षण अनुबंध द्वारा एक सख्त, लिखित डिज़ाइन प्रदान करता है जो कोड के टुकड़े को संतुष्ट करना चाहिए। नतीजतन, यह कई लाभ प्रदान करता है।
इकाई परीक्षण विकास चक्र में शुरुआती समस्याओं का पता लगाता है। इसमें प्रोग्रामर के कार्यान्वयन में बग और इकाई के लिए विनिर्देश के दोष या गायब हिस्से दोनों सम्मिलितहैं। परीक्षणों का एक संपूर्ण सेट लिखने की प्रक्रिया लेखक को इनपुट, आउटपुट और त्रुटि स्थितियों के माध्यम से सोचने के लिए मजबूर करती है, और इस प्रकार इकाई के वांछित व्यवहार को और अधिक स्पष्ट रूप से परिभाषित करती है। कोडिंग शुरू होने से पहले बग को खोजने की लागत या जब कोड पहली बार लिखा जाता है, बाद में बग का पता लगाने, पहचानने और ठीक करने की लागत से काफी कम होता है। जारी किए गए कोड में बग भी सॉफ़्टवेयर के अंतिम-उपयोगकर्ताओं के लिए महंगी समस्याएँ पैदा कर सकते हैं।[9][10][11] खराब लिखे जाने पर इकाई परीक्षण के लिए कोड असंभव या कठिन हो सकता है, इस प्रकार इकाई परीक्षण डेवलपर्स को बेहतर तरीके से संरचना कार्यों और वस्तुओं के लिए मजबूर कर सकता है।
परीक्षण-संचालित विकास (टीडीडी) में, जो प्रायः चरम कार्यक्रम और स्क्रम (सॉफ्टवेयर विकास) दोनों में उपयोग किया जाता है, कोड लिखे जाने से पहले इकाई परीक्षण बनाए जाते हैं। जब परीक्षण पास हो जाते हैं, तो वह कोड पूर्ण माना जाता है। उसी इकाई परीक्षण को उस फ़ंक्शन के खिलाफ प्रायः चलाया जाता है क्योंकि बड़ा कोड बेस विकसित होता है या तो कोड बदल जाता है या निर्माण के सापेक्षस्वचालित प्रक्रिया के माध्यम से। यदि इकाई परीक्षण विफल हो जाते हैं, तो इसे या तो बदले हुए कोड में या स्वयं परीक्षणों में एक बग माना जाता है। इकाई परीक्षण तब गलती या विफलता के स्थान को आसानी से पता लगाने की अनुमति देता है। चूंकि इकाई परीक्षण समस्या के विकास दल को परीक्षकों या ग्राहकों को कोड सौंपने से पहले सचेत करता है, संभावित समस्याओं को विकास प्रक्रिया में जल्दी पकड़ा जाता है।
इकाई परीक्षण प्रोग्रामर को बाद की तारीख में कोड को पुनर्रचना या सिस्टम लाइब्रेरी को अपग्रेड करने की अनुमति देता है, और यह सुनिश्चित करता है कि मॉड्यूल अभी भी सही तरीके से काम करता है (उदाहरण के लिए, प्रतिगमन परीक्षण में)। प्रक्रिया सभी सबरूटीन्स और विधि (कंप्यूटर विज्ञान) के लिए टेस्ट केस लिखने के लिए है यद्यपि जब भी कोई बदलाव गलती का कारण बनता है, तो इसे जल्दी से पहचाना जा सके। इकाई परीक्षण उन परिवर्तनों का पता लगाते हैं जो अनुबंध द्वारा डिजाइन को तोड़ सकते हैं।
इकाई परीक्षण स्वयं इकाइयों में अनिश्चितता को कम कर सकता है और इसका उपयोग टॉप-डाउन और बॉटम-अप डिज़ाइन | बॉटम-अप परीक्षण शैली दृष्टिकोण में किया जा सकता है। किसी प्रोग्राम के भागों का पहले परीक्षण करके और फिर उसके भागों के योग का परीक्षण करके, एकीकरण परीक्षण बहुत आसान हो जाता है।[citation needed]
इकाई परीक्षण प्रणाली का एक प्रकार का जीवित दस्तावेज प्रदान करता है। इकाई द्वारा कौन सी कार्यक्षमता प्रदान की जाती है, और इसका उपयोग कैसे करना है, यह जानने के इच्छुक डेवलपर्स इकाई के इंटरफ़ेस (अप्लिकेशन प्रोग्रामिंग अंतरफलक) की बुनियादी समझ हासिल करने के लिए इकाई परीक्षण देख सकते हैं।[citation needed]
इकाई परीक्षण के मामले उन विशेषताओं को सम्मिलितकरते हैं जो इकाई की सफलता के लिए महत्वपूर्ण हैं। ये विशेषताएँ एक इकाई के उचित/अनुचित उपयोग के साथ-सापेक्षनकारात्मक व्यवहारों को इंगित कर सकती हैं जिन्हें इकाई द्वारा फंसाया जाना है। एक इकाई परीक्षण मामला, अपने आप में, इन महत्वपूर्ण विशेषताओं को प्रलेखित करता है, हालांकि कई सॉफ्टवेयर विकास वातावरण विकास में उत्पाद को प्रलेखित करने के लिए केवल कोड पर निर्भर नहीं होते हैं।[citation needed]
जब परीक्षण-संचालित दृष्टिकोण का उपयोग करके सॉफ़्टवेयर विकसित किया जाता है, तो इंटरफ़ेस निर्दिष्ट करने के लिए इकाई टेस्ट लिखने का संयोजन और परीक्षण पारित होने के बाद की गई रीफैक्टरिंग गतिविधियां औपचारिक डिजाइन की जगह ले सकती हैं। प्रत्येक इकाई परीक्षण को कक्षाओं, विधियों और अवलोकनीय व्यवहार को निर्दिष्ट करने वाले एक डिजाइन तत्व के रूप में देखा जा सकता है।[citation needed]
सीमाएं और नुकसान
परीक्षण कार्यक्रम में हर त्रुटि को नहीं पकड़ेगा, क्योंकि यह किसी भी निष्पादन पथ का मूल्यांकन नहीं कर सकता है परंतु सबसे तुच्छ कार्यक्रम है। यह निर्णय समस्या हॉल्टिंग समस्या का सुपरसेट है, जो कि अनिर्णीत समस्या है। इकाई परीक्षण के लिए भी यही सच है। इसके अतिरिक्त, परिभाषा के अनुसार इकाई परीक्षण केवल स्वयं इकाइयों की कार्यक्षमता का परीक्षण करता है। इसलिए, यह एकीकरण त्रुटियों या व्यापक सिस्टम-स्तरीय त्रुटियों को नहीं पकड़ेगा (जैसे कि कई इकाइयों में किए गए कार्य, या गैर-कार्यात्मक परीक्षण क्षेत्र जैसे सॉफ़्टवेयर प्रदर्शन परीक्षण)। इकाई परीक्षण अन्य सॉफ्टवेयर परीक्षण गतिविधियों के संयोजन में किया जाना चाहिए, क्योंकि वे केवल विशेष त्रुटियों की उपस्थिति या अनुपस्थिति दिखा सकते हैं; वे त्रुटियों के पूर्ण अभाव को साबित नहीं कर सकते। प्रत्येक निष्पादन पथ और हर संभव इनपुट के लिए सही व्यवहार की गारंटी देने के लिए, और त्रुटियों की अनुपस्थिति को सुनिश्चित करने के लिए, अन्य तकनीकों की आवश्यकता होती है, अर्थात् यह साबित करने के लिए औपचारिक सत्यापन का अनुप्रयोग कि सॉफ़्टवेयर घटक में कोई अप्रत्याशित व्यवहार नहीं है।[citation needed]
इकाई परीक्षणों का एक विस्तृत पदानुक्रम एकीकरण परीक्षण के बराबर नहीं है। परिधीय इकाइयों के सापेक्षएकीकरण को एकीकरण परीक्षणों में सम्मिलितकिया जाना चाहिए, परंतु इकाई परीक्षणों में नहीं।[citation needed] एकीकरण परीक्षण आमतौर पर अभी भी मानव के मैनुअल परीक्षण पर बहुत अधिक निर्भर करता है; उच्च-स्तरीय या वैश्विक-दायरे के परीक्षण को स्वचालित करना मुश्किल हो सकता है, जैसे मैन्युअल परीक्षण प्रायः तेज़ और सस्ता दिखाई देता है।[citation needed]
सॉफ्टवेयर परीक्षण एक मिश्रित समस्या है। उदाहरण के लिए, प्रत्येक बूलियन निर्णय कथन के लिए कम से कम दो परीक्षणों की आवश्यकता होती है: एक सत्य के परिणाम के सापेक्षऔर एक गलत के परिणाम के साथ। परिणामस्वरूप, लिखे गए कोड की प्रत्येक पंक्ति के लिए, प्रोग्रामर को प्रायः टेस्ट कोड की 3 से 5 पंक्तियों की आवश्यकता होती है।[12] इसमें स्पष्ट रूप से समय लगता है और इसका निवेश प्रयास के लायक नहीं हो सकता है। ऐसी समस्याएं हैं जिनका आसानी से बिल्कुल भी परीक्षण नहीं किया जा सकता है - उदाहरण के लिए वे जो गैर नियतात्मक एल्गोरिथम हैं या जिसमें कई थ्रेड (कंप्यूटर साइंस) सम्मिलितहैं। इसके अलावा, इकाई परीक्षण के लिए कोड उतना ही छोटा होने की संभावना है जितना कोड परीक्षण कर रहा है। द मिथिकल मैन-मंथ में फ्रेड ब्रूक्स उद्धरण: कभी भी दो क्रोनोमीटर के सापेक्षसमुद्र में न जाएं; एक या तीन लो।[13] मतलब, अगर दो समुद्री क्रोनोमीटर विरोधाभासी हैं, तो आप कैसे जानेंगे कि कौन सा सही है?
इकाई परीक्षण लिखने से जुड़ी एक अन्य चुनौती यथार्थवादी और उपयोगी परीक्षण स्थापित करने की कठिनाई है। प्रासंगिक प्रारंभिक स्थितियां बनाना आवश्यक है यद्यपि परीक्षण किए जा रहे एप्लिकेशन का हिस्सा पूरी प्रणाली के हिस्से की तरह व्यवहार करे। यदि इन प्रारंभिक स्थितियों को सही ढंग से सेट नहीं किया गया है, तो परीक्षण यथार्थवादी संदर्भ में कोड का प्रयोग नहीं करेगा, जो इकाई परीक्षण परिणामों के मूल्य और सटीकता को कम करता है।[14] इकाई परीक्षण से इच्छित लाभ प्राप्त करने के लिए, सॉफ्टवेयर विकास प्रक्रिया के दौरान कठोर अनुशासन की आवश्यकता होती है। न केवल किए गए परीक्षणों का सावधानीपूर्वक रिकॉर्ड रखना आवश्यक है, बल्कि इस या सॉफ़्टवेयर की किसी अन्य इकाई के स्रोत कोड में किए गए सभी परिवर्तनों का भी रिकॉर्ड रखना आवश्यक है। एक संस्करण नियंत्रण प्रणाली का उपयोग आवश्यक है। यदि इकाई का बाद का संस्करण किसी विशेष परीक्षण में विफल रहता है जिसे वह पहले पारित कर चुका था, तो संस्करण-नियंत्रण सॉफ़्टवेयर स्रोत कोड परिवर्तनों (यदि कोई हो) की एक सूची प्रदान कर सकता है जो उस समय से इकाई पर लागू किए गए हैं।[citation needed]
यह सुनिश्चित करने के लिए एक स्थायी प्रक्रिया को लागू करना भी आवश्यक है कि परीक्षण मामले की विफलताओं की नियमित रूप से समीक्षा की जाती है और तुरंत संबोधित किया जाता है।[15] यदि इस तरह की प्रक्रिया को लागू नहीं किया जाता है और टीम के वर्कफ़्लो में सम्मिलितहो जाता है, तो एप्लिकेशन इकाई टेस्ट सूट के सापेक्षसिंक से बाहर हो जाएगा, झूठी सकारात्मकता बढ़ जाएगी और टेस्ट सूट की प्रभावशीलता कम हो जाएगी।
इकाई परीक्षण एम्बेडेड सिस्टम सॉफ़्टवेयर एक अनूठी चुनौती प्रस्तुत करता है: क्योंकि सॉफ़्टवेयर को एक अलग प्लेटफ़ॉर्म पर विकसित किया जा रहा है, जिस पर वह अंततः चलेगा, आप वास्तविक परिनियोजन वातावरण में एक परीक्षण प्रोग्राम को आसानी से नहीं चला सकते हैं, जैसा कि डेस्कटॉप प्रोग्राम के सापेक्षसंभव है।[16] इकाई परीक्षण सबसे आसान होते हैं जब किसी विधि में इनपुट पैरामीटर और कुछ आउटपुट होते हैं। इकाई परीक्षण बनाना उतना आसान नहीं है जब विधि का एक प्रमुख कार्य अनुप्रयोग के लिए किसी बाहरी चीज़ के सापेक्षसहभागिता करना हो। उदाहरण के लिए, एक विधि जो डेटाबेस के सापेक्षकाम करेगी, उसे बनाने के लिए डेटाबेस इंटरैक्शन के मॉक अप की आवश्यकता हो सकती है, जो संभवतः वास्तविक डेटाबेस इंटरैक्शन के रूप में व्यापक नहीं होगा।[17][better source needed]
उदाहरण
यहाँ जावा (प्रोग्रामिंग भाषा) में परीक्षण मामलों का एक सेट है जो कार्यान्वयन के कई तत्वों को निर्दिष्ट करता है। सबसे पहले, एडर नामक एक इंटरफ़ेस होना चाहिए, और एक शून्य-तर्क निर्माता के सापेक्षएक कार्यान्वयन वर्ग जिसे AdderImpl कहा जाता है। यह अभिकथन (कंप्यूटिंग) पर जाता है कि योजक इंटरफ़ेस में दो पूर्णांक मापदंडों के सापेक्षऐड नामक एक विधि होनी चाहिए, जो एक और पूर्णांक लौटाती है। यह कई परीक्षण विधियों पर मूल्यों की एक छोटी श्रृंखला के लिए इस पद्धति के व्यवहार को भी निर्दिष्ट करता है।
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class TestAdder {
// can it add the positive numbers 1 and 1?
@Test
public void testSumPositiveNumbersOneAndOne() {
Adder adder = new AdderImpl();
assertEquals(2, adder.add(1, 1));
}
// can it add the positive numbers 1 and 2?
@Test
public void testSumPositiveNumbersOneAndTwo() {
Adder adder = new AdderImpl();
assertEquals(3, adder.add(1, 2));
}
// can it add the positive numbers 2 and 2?
@Test
public void testSumPositiveNumbersTwoAndTwo() {
Adder adder = new AdderImpl();
assertEquals(4, adder.add(2, 2));
}
// is zero neutral?
@Test
public void testSumZeroNeutral() {
Adder adder = new AdderImpl();
assertEquals(0, adder.add(0, 0));
}
// can it add the negative numbers -1 and -2?
@Test
public void testSumNegativeNumbers() {
Adder adder = new AdderImpl();
assertEquals(-3, adder.add(-1, -2));
}
// can it add a positive and a negative?
@Test
public void testSumPositiveAndNegative() {
Adder adder = new AdderImpl();
assertEquals(0, adder.add(-1, 1));
}
// how about larger numbers?
@Test
public void testSumLargeNumbers() {
Adder adder = new AdderImpl();
assertEquals(2222, adder.add(1234, 988));
}
}
इस मामले में इकाई परीक्षण, पहले लिखे जाने के बाद, एक वांछित समाधान के रूप और व्यवहार को निर्दिष्ट करने वाले एक डिज़ाइन दस्तावेज़ के रूप में कार्य करता है, परंतु कार्यान्वयन विवरण नहीं, जो प्रोग्रामर के लिए छोड़ दिया जाता है। सबसे आसान काम करने का पालन करना जो संभवत: अभ्यास का काम कर सकता है, सबसे आसान समाधान जो टेस्ट पास करेगा, नीचे दिखाया गया है।
interface Adder {
int add(int a, int b);
}
class AdderImpl implements Adder {
public int add(int a, int b) {
return a + b;
}
}
निष्पादन योग्य विनिर्देशों के रूप में
डिज़ाइन विनिर्देश के रूप में इकाई-टेस्ट का उपयोग करने से अन्य डिज़ाइन विधियों पर एक महत्वपूर्ण लाभ होता है: डिज़ाइन दस्तावेज़ (इकाई-परीक्षण स्वयं) का उपयोग कार्यान्वयन को सत्यापित करने के लिए किया जा सकता है। जब तक डेवलपर डिजाइन के अनुसार समाधान लागू नहीं करता तब तक परीक्षण कभी पास नहीं होंगे।
इकाई परीक्षण में एकीकृत मॉडलिंग भाषा आरेख जैसे डायग्रामेटिक विनिर्देश की कुछ पहुंच की कमी है, परंतु वे स्वचालित टूल का उपयोग करके इकाई परीक्षण से उत्पन्न हो सकते हैं। अधिकांश आधुनिक भाषाओं में नि: शुल्क उपकरण होते हैं (आमतौर पर एकीकृत विकास परिवेशों के विस्तार के रूप में उपलब्ध होते हैं)। नि: शुल्क उपकरण, जैसे कि xUnit ढांचे पर आधारित, मानव उपभोग के लिए एक दृश्य के चित्रमय प्रतिपादन के लिए किसी अन्य प्रणाली को आउटसोर्स करते हैं।
अनुप्रयोग
चरम प्रोग्रामिंग
इकाई परीक्षण एक्सट्रीम प्रोग्रामिंग की आधारशिला हैइकाई परीक्षण ढांचे की सूची की एक स्वचालित सूची पर निर्भर करती है। यह स्वचालित इकाई परीक्षण ढांचा या तो तृतीय पक्ष हो सकता है, उदाहरण के लिए, xUnit, या विकास समूह के भीतर बनाया गया।
चरम प्रोग्रामिंग परीक्षण-संचालित विकास के लिए इकाई परीक्षणों के निर्माण का उपयोग करती है। डेवलपर एक इकाई परीक्षण लिखता है जो सॉफ़्टवेयर आवश्यकता या दोष को उजागर करता है। यह परीक्षण विफल हो जाएगा क्योंकि या तो आवश्यकता अभी तक लागू नहीं हुई है, या क्योंकि यह जानबूझकर मौजूदा कोड में एक दोष को उजागर करता है। फिर, डेवलपर परीक्षण करने के लिए सबसे सरल कोड लिखता है, अन्य परीक्षणों के साथ, पास करता है।
सिस्टम में अधिकांश कोड इकाई टेस्टेड होते हैं, परंतु जरूरी नहीं कि कोड के माध्यम से सभी पथ हों। एक्सट्रीम प्रोग्रामिंग के लिए हर उस चीज का परीक्षण अनिवार्य है जो संभवतः रणनीति को तोड़ सकती है, पारंपरिक परीक्षण पर प्रत्येक निष्पादन पथ विधि। यह डेवलपर्स को शास्त्रीय तरीकों की तुलना में कम परीक्षण विकसित करने की ओर ले जाता है, परंतु यह वास्तव में एक समस्या नहीं है, तथ्य की अधिक पुनरावृत्ति है, क्योंकि सभी निष्पादन पथों को पूरी तरह से परीक्षण करने के लिए शास्त्रीय तरीकों का शायद ही कभी पर्याप्त रूप से पालन किया गया है।[citation needed] एक्सट्रीम प्रोग्रामिंग केवल यह पहचानती है कि परीक्षण शायद ही कभी संपूर्ण होता है (क्योंकि यह आर्थिक रूप से व्यवहार्य होने के लिए प्रायः बहुत महंगा और समय लेने वाला होता है) और सीमित संसाधनों को प्रभावी ढंग से केंद्रित करने के तरीके पर मार्गदर्शन प्रदान करता है।
महत्वपूर्ण रूप से, परीक्षण कोड को प्रथम श्रेणी का प्रोजेक्ट आर्टिफैक्ट माना जाता है जिसमें इसे कार्यान्वयन कोड के समान गुणवत्ता पर बनाए रखा जाता है, जिसमें सभी दोहराव हटा दिए जाते हैं। डेवलपर्स इकाई परीक्षण कोड को कोड रिपॉजिटरी में उस कोड के सापेक्षजारी करते हैं जो वह परीक्षण करता है। एक्सट्रीम प्रोग्रामिंग का पूर्ण इकाई परीक्षण उपरोक्त लाभों की अनुमति देता है, जैसे कि सरल और अधिक विश्वसनीय कोड विकास और रीफैक्टरिंग, सरलीकृत कोड एकीकरण, सटीक प्रलेखन और अधिक मॉड्यूलर डिज़ाइन। ये इकाई परीक्षण भी प्रतिगमन परीक्षण के रूप में लगातार चलाए जाते हैं।
इमर्जेंट डिज़ाइन की अवधारणा के लिए इकाई परीक्षण भी महत्वपूर्ण है। जैसा कि आकस्मिक डिजाइन रिफैक्टरिंग पर बहुत अधिक निर्भर है, इकाई परीक्षण एक अभिन्न अंग हैं।[18]
इकाई परीक्षण फ्रेमवर्क
इकाई परीक्षण फ्रेमवर्क प्रायः तीसरे पक्ष के उत्पाद होते हैं जिन्हें कंपाइलर सूट के हिस्से के रूप में वितरित नहीं किया जाता है। वे इकाई परीक्षण फ्रेमवर्क की सूची के लिए विकसित किए जाने के बाद इकाई परीक्षण की प्रक्रिया को आसान बनाने में मदद करते हैं।
क्लाइंट कोड लिखकर एक विशिष्ट ढांचे के समर्थन के बिना इकाई परीक्षण करना आम तौर पर संभव है जो परीक्षण के तहत इकाइयों का प्रयोग करता है और विफलता संकेत करने के लिए अभिकथन (सॉफ्टवेयर विकास), अपवाद हैंडलिंग, या अन्य नियंत्रण प्रवाह तंत्र का उपयोग करता है। एक ढांचे के बिना इकाई परीक्षण इस मायने में मूल्यवान है कि इकाई परीक्षण को अपनाने के लिए प्रवेश में बाधा है; अल्प इकाई परीक्षण होना शायद ही कोई नहीं होने से बेहतर है, जबकि एक बार एक ढांचा होने के बाद, इकाई परीक्षण जोड़ना अपेक्षाकृत आसान हो जाता है।[19] कुछ रूपरेखाओं में कई उन्नत इकाई परीक्षण सुविधाएँ गायब हैं या उन्हें हाथ से कोडित किया जाना चाहिए।
भाषा-स्तरीय इकाई परीक्षण समर्थन
कुछ प्रोग्रामिंग लैंग्वेज सीधे इकाई परीक्षण को सपोर्ट करती हैं। उनका व्याकरण पुस्तकालय आयात किए बिना इकाई परीक्षणों की प्रत्यक्ष घोषणा की अनुमति देता है । इसके अतिरिक्त, इकाई परीक्षणों की बूलियन स्थितियों को उसी सिंटैक्स में व्यक्त किया जा सकता है जैसे गैर-इकाई टेस्ट कोड में उपयोग किए जाने वाले बूलियन एक्सप्रेशन, जैसे कि किसके लिए उपयोग किया जाता है if और while कथन।
अंतर्निहित इकाई परीक्षण समर्थन वाली भाषाओं में सम्मिलित हैं:
मानक इकाई परीक्षण ढांचे के समर्थन वाली भाषाओं में सम्मिलित हैं:
रेफरी>"न्यूनतम (रूबी 2.0)". Ruby-Doc.org.</ref>
कुछ भाषाओं में बिल्ट-इन इकाई-परीक्षण सपोर्ट नहीं करता है, परंतु इकाई परीक्षण लाइब्रेरी या फ्रेमवर्क स्थापित हैं। इन भाषाओं में सम्मिलित हैं:
- एबीएपी
- सी ++
- C# (सी शार्प)
- क्लोजर[28]
- एलिक्सिर
- जावा
- जावास्क्रिप्ट
- ऑब्जेक्टिव सी
- पर्ल
- पीएचपी
- विंडोज पॉवरशेल
"पेस्टर फ्रेमवर्क". GitHub. Retrieved 28 January 2016.
यह भी देखें
- स्वीकृति परीक्षण
- लक्षण वर्णन परीक्षण
- घटक-आधारित उपयोगिता परीक्षण
- डिजाइन भविष्यवाणी करता है
- अनुबंध द्वारा डिजाइन
- चरम कार्यक्रम
- क्रियात्मक परीक्षण
- एकीकरण जांच
- यूनिट टेस्टिंग फ्रेमवर्क की सूची
- प्रतिगमन परीक्षण
- सॉफ्टवेयर पुरातत्व
- सॉफ़्टवेयर परीक्षण
- परीक्षण मामला
- परीक्षण संचालित विकास
- 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.
