यूनिट टेस्टिंग क्या है?

यूनिट टेस्टिंग क्या है?

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

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

उदाहरण के लिए, में Python:

def add (a, b): 
return a + b 
def test_add():
assert add(2, 3) == 5

यह सरल परीक्षण यह जांचता है कि क्या add फ़ंक्शन सही परिणाम देता है। हालाँकि यह सरल है, यह इस विचार को दर्शाता है: बाकी सिस्टम के साथ एकीकरण करने से पहले तर्क को स्वतंत्र रूप से सत्यापित करें।

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

👉 निःशुल्क लाइव यूनिट परीक्षण परियोजना के लिए नामांकन करें

यूनिट परीक्षण क्यों करें?

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

सॉफ्टवेयर इंजीनियरिंग में यूनिट परीक्षण करने के प्रमुख कारण यहां दिए गए हैं:

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

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

यूनिट परीक्षण वीडियो स्पष्टीकरण

यूनिट परीक्षण कैसे निष्पादित करें?

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

चरण 1) इकाई का विश्लेषण करें और मामलों को परिभाषित करें

सबसे छोटे परीक्षण योग्य व्यवहार की पहचान करें। सूची बनाएँ खुशहाल रास्ते, किनारे के मामले, तथा त्रुटि की स्थितियाँइनपुट/आउटपुट और पूर्व/पश्चात शर्तों को स्पष्ट करें।

चरण 2) परीक्षण वातावरण सेट करें

फ्रेमवर्क चुनें, न्यूनतम फिक्स्चर लोड करें, और निर्भरताओं को अलग करें (मॉक्स/स्टब्स/नकली)। धीमे, भंगुर परीक्षणों से बचने के लिए सेटअप को हल्का रखें।

चरण 3) टेस्ट लिखें (AAA पैटर्न)

की व्यवस्था इनपुट और संदर्भ → अधिनियम यूनिट को कॉल करके → जोर अपेक्षित परिणाम। आंतरिक कार्यान्वयन विवरणों की तुलना में व्यवहार संबंधी कथनों को प्राथमिकता दें।

# Arrange
cart = Cart(tax_rate=0.1)
# Act
total = cart.total([Item("book", 100)])
# Assert
assert total == 110

चरण 4) स्थानीय रूप से और CI में चलाएँ

पहले अपनी मशीन पर परीक्षण चलाएँ; फिर स्वच्छ वातावरण जाँच के लिए CI में चलाएँ। शीघ्र विफल हों; लॉग संक्षिप्त और कार्रवाई योग्य रखें।

चरण 5) विफलताओं का निदान करें, ठीक करें और पुनर्रचना करें

जब कोई परीक्षण विफल हो जाता है, कोड या परीक्षण को ठीक करेंदोनों एक साथ नहीं। हरे रंग के बाद, आत्मविश्वास के साथ रिफैक्टर करें—गार्ड व्यवहार का परीक्षण करें।

चरण 6) पुनः चलाएँ, Revदेखें, और बनाए रखें

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

प्रो टिप्स:

• परीक्षण रखें तेज (<200 एमएस प्रत्येक) और स्वतंत्र.
• के लिए नाम परीक्षण व्यवहार (जैसे, test_total_includes_tax).
• चंचलता को एक बग के रूप में समझें; संगरोध करें, मूल कारण को ठीक करें, फिर पुनः सक्षम करें।

विभिन्न यूनिट परीक्षण तकनीकें क्या हैं?

यूनिट परीक्षण सबसे अधिक प्रभावी तब होते हैं जब वे मिश्रित होते हैं स्मार्ट परीक्षण डिज़ाइन तकनीकें साथ में समझदार कवरेज लक्ष्यजहां जरूरी हो वहां चौड़ाई का लक्ष्य रखें, जहां जोखिम सबसे अधिक हो वहां गहराई का लक्ष्य रखें, और "100% या बर्बाद" जाल का विरोध करें।

RSI यूनिट परीक्षण तकनीकें मुख्यतः तीन भागों में वर्गीकृत किया गया है:

1. ब्लैक बॉक्स परीक्षण इसमें इनपुट और आउटपुट के साथ-साथ उपयोगकर्ता इंटरफ़ेस का परीक्षण भी शामिल है
2. सफेद बॉक्स परीक्षण इसमें सॉफ़्टवेयर एप्लिकेशन के कार्यात्मक व्यवहार का परीक्षण शामिल है
3. ग्रे बॉक्स परीक्षण परीक्षण सूट, परीक्षण विधियों और परीक्षण मामलों को निष्पादित करने और जोखिम विश्लेषण करने के लिए उपयोग किया जाता है

कवरेज एक है अग्रणी सूचक, अंतिम रेखा नहीं। इसका उपयोग करें अंधे स्थानों का पता लगाएंसंख्या में हेराफेरी करने के लिए नहीं। Code यूनिट टेस्टिंग में उपयोग की जाने वाली कवरेज तकनीकें नीचे सूचीबद्ध हैं:

• वक्तव्य कवरेज
• निर्णय कवरेज
• शाखा कवरेज
• स्थिति कवरेज
• परिमित राज्य मशीन कवरेज

अधिक पर लिए Code कवरेज, संदर्भ https://www.guru99.com/code-coverage.html

यूनिट परीक्षण में मॉकिंग और स्टबिंग की क्या भूमिका है?

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

परीक्षण का उपयोग क्यों करें Doubles?

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

स्टब्स

A ठूंठ यह एक सरलीकृत प्रतिस्थापन है जो एक निश्चित प्रतिक्रिया देता है। यह बातचीत रिकॉर्ड नहीं करता - यह केवल तैयार डेटा प्रदान करता है।

उदाहरण (Python):

def get_user_from_db(user_id):
# Imagine a real DB call here
raise NotImplementedError()
def test_returns_user_with_stub(monkeypatch):
# Arrange: stubbed DB call
monkeypatch.setattr("app.get_user_from_db", lambda _: {"id": 1, "name": "Alice"})
# Act
user = get_user_from_db(1)
# Assert
assert user["name"] == "Alice"

मजाक उड़ाता है

A दिखावटी अधिक शक्तिशाली है: यह अंतःक्रियाओं को सत्यापित कर सकता है (उदाहरण के लिए, "क्या इस विधि को X के साथ बुलाया गया था?")।

उदाहरण (Javaजेस्ट के साथ स्क्रिप्ट):

const sendEmail = jest.fn();
function registerUser(user, emailService) {
emailService(user.email, "Welcome!");
test("sends welcome email", () => {
// Arrange
const user = { email: "test@example.com" };
// Act
registerUser(user, sendEmail);
// Assert
expect(sendEmail).toHaveBeenCalledWith("test@example.com", "Welcome!");

});

यहां ही दिखावटी यह जांचता है कि ईमेल सेवा सही ढंग से कॉल की गई थी - ऐसा कुछ जो स्टब नहीं कर सकता।

आम समस्याएं

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

अंगूठे का नियम

• जब आपको केवल डेटा की आवश्यकता हो तो स्टब का उपयोग करें.
• जब आपको इंटरैक्शन सत्यापित करने की आवश्यकता हो तो मॉक करें.
• भारी नकली की तुलना में नकली को प्राथमिकता दें जब आप कर सकते हैं (उदाहरण के लिए, प्रत्येक क्वेरी का मॉकिंग करने के बजाय इन-मेमोरी डीबी)।

नीचे पंक्ति: मज़ाक करना और स्टबिंग करना सहायक अभिनेतातारों का नहीं, बल्कि तारों का। अपनी यूनिट को अलग-थलग करने के लिए इनका इस्तेमाल करें, लेकिन उन्हें टेस्ट सूट पर कब्ज़ा न करने दें।

सामान्य यूनिट परीक्षण उपकरण कौन से हैं?

सॉफ़्टवेयर परीक्षण में यूनिट परीक्षण में सहायता के लिए कई स्वचालित यूनिट परीक्षण सॉफ़्टवेयर उपलब्ध हैं। हम नीचे कुछ उदाहरण प्रदान करेंगे:

1. JUnit: जूनिट एक निःशुल्क परीक्षण उपकरण है जिसका उपयोग किया जाता है Java प्रोग्रामिंग भाषा। यह परीक्षण विधि की पहचान करने के लिए अभिकथन प्रदान करता है। यह उपकरण पहले डेटा का परीक्षण करता है और फिर उसे कोड के एक भाग में सम्मिलित करता है।
2. नुनीतNUnit सभी .NET भाषाओं के लिए एक व्यापक रूप से उपयोग किया जाने वाला यूनिट-टेस्टिंग फ्रेमवर्क है। यह एक ओपन-सोर्स टूल है जो स्क्रिप्ट को मैन्युअल रूप से लिखने की अनुमति देता है। यह डेटा-संचालित परीक्षणों का समर्थन करता है, जिन्हें समानांतर रूप से चलाया जा सकता है।
3. PHPUnitPHPUnit, PHP प्रोग्रामर्स के लिए एक यूनिट टेस्टिंग टूल है। यह कोड के छोटे-छोटे हिस्सों, जिन्हें यूनिट कहा जाता है, को लेता है और उनमें से प्रत्येक का अलग-अलग परीक्षण करता है। यह टूल डेवलपर्स को पूर्वनिर्धारित अभिकथन विधियों का उपयोग करके यह सुनिश्चित करने की भी अनुमति देता है कि कोई सिस्टम एक निश्चित तरीके से काम करता है।

ये उपलब्ध यूनिट परीक्षण उपकरणों में से कुछ ही हैं। और भी बहुत सारे हैं, खास तौर पर सी भाषाएँ और Java, लेकिन आप अपनी प्रोग्रामिंग आवश्यकताओं के लिए एक यूनिट परीक्षण उपकरण अवश्य पा लेंगे, चाहे आप किसी भी भाषा का उपयोग करें।

परीक्षण संचालित विकास (TDD) और यूनिट परीक्षण

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

• परीक्षण कोड से पहले लिखे जाते हैं
• परीक्षण ढाँचों पर अत्यधिक निर्भर रहना
• अनुप्रयोगों में सभी वर्गों का परीक्षण किया जाता है
• त्वरित एवं आसान एकीकरण संभव हो गया है

टीडीडी के कुछ लाभ इस प्रकार हैं:

• छोटी, परीक्षण योग्य इकाइयों और सरल डिजाइनों को प्रोत्साहित करता है।
• अति-इंजीनियरिंग से बचाव; आप केवल वही निर्माण करते हैं जिसकी परीक्षण में मांग होती है।
• रिफैक्टर्स के लिए एक जीवंत सुरक्षा जाल प्रदान करता है।

विशेषज्ञो कि सलाह: जब चाहें TDD चुनें सख्त डिज़ाइन प्रतिक्रिया कोड स्तर पर और इकाइयों पर तीव्र, वृद्धिशील प्रगति।

यूनिट परीक्षणों को CI/CD में क्यों एकीकृत किया जाए?

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

CI/CD पाइपलाइनों में यूनिट परीक्षणों को एकीकृत करने के कारण यहां दिए गए हैं:

• तत्काल प्रतिक्रिया - डेवलपर्स को कुछ ही मिनटों में पता चल जाता है कि उनके बदलाव से कुछ टूटा है।
• Shift-बाएं गुणवत्ता - बग्स को कमिट के समय पकड़ा जाता है, रिलीज के बाद नहीं।
• तैनाती में विश्वास - स्वचालित जांच यह सुनिश्चित करती है कि "ग्रीन बिल्ड" को आगे बढ़ाना सुरक्षित है।
• स्केलेबल सहयोग – किसी भी आकार की टीमें बिना किसी चरण के कोड को मर्ज कर सकती हैंping एक दूसरे पर।

यूनिट परीक्षण मिथक

यूनिट परीक्षण के बारे में कुछ सामान्य मिथक इस प्रकार हैं:

"इसमें समय लगता है, और मैं हमेशा बहुत व्यस्त रहता हूँ। मेरा कोड बहुत मज़बूत है! मुझे यूनिट टेस्ट की ज़रूरत नहीं है।"

मिथक अपने स्वभाव से ही गलत धारणाएँ हैं। ये धारणाएँ एक दुष्चक्र की ओर ले जाती हैं, जो इस प्रकार है -

सच तो यह है कि यूनिट परीक्षण से विकास की गति बढ़ जाती है।

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

यूनिट परीक्षण का लाभ

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

यूनिट परीक्षण के नुकसान

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

यह अनुशंसित है कि यूनिट परीक्षण का उपयोग अन्य परीक्षण गतिविधियों के साथ किया जाए।

यूनिट परीक्षण के सर्वोत्तम अभ्यास

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

अक्सर पूछे जाने वाले प्रश्न

सारांश