unit-testing
सभी भाषाओं के लिए यूनिट परीक्षण के सामान्य नियम
खोज…
परिचय
इकाई-परीक्षण से शुरू होने पर सभी प्रकार के प्रश्न सामने आते हैं:
यूनिट-परीक्षण क्या है? एक सेटअप और टियरडाउन क्या है? मैं निर्भरता से कैसे निपटूं? यूनिट-टेस्टिंग बिल्कुल क्यों? मैं अच्छे यूनिट टेस्ट कैसे कर सकता हूं?
यह लेख इन सभी सवालों का जवाब देगा, इसलिए आप अपनी इच्छानुसार किसी भी भाषा में इकाई-परीक्षण शुरू कर सकते हैं।
टिप्पणियों
यूनिट परीक्षण क्या है?
यूनिट टेस्टिंग यह सुनिश्चित करने के लिए कोड का परीक्षण है कि यह उस कार्य को करता है जिसका प्रदर्शन करना है। यह बहुत कम संभव स्तर पर कोड का परीक्षण करता है - आपकी कक्षाओं के व्यक्तिगत तरीके।
एक इकाई क्या है?
कोड का कोई असतत मॉड्यूल जिसे अलगाव में परीक्षण किया जा सकता है। अधिकांश समय कक्षाएं और उनके तरीके। इस वर्ग को आम तौर पर "क्लास अंडर टेस्ट" (CUT) या "सिस्टम अंडर टेस्ट" (SUT) कहा जाता है
इकाई परीक्षण और एकीकरण परीक्षण के बीच अंतर
यूनिट परीक्षण अलगाव में एकल वर्ग का परीक्षण करने का कार्य है, जो वास्तव में इसके किसी भी निर्भरता से पूरी तरह से अलग है। एकीकरण परीक्षण एक एकल वर्ग के परीक्षण के साथ-साथ इसकी वास्तविक निर्भरता के एक या अधिक परीक्षण का कार्य है।
सेटअप और टियरडाउन
जब सेटअप विधि को प्रत्येक इकाई परीक्षण से पहले चलाया जाता है और प्रत्येक परीक्षण के बाद टियरडाउन।
सामान्य तौर पर आप सेटअप में सभी पूर्वापेक्षाओं को जोड़ते हैं और टियरडाउन में सभी क्लीन-अप चरणों को। लेकिन आप केवल इन विधियों को बनाते हैं यदि इन परीक्षणों की आवश्यकता हर परीक्षण के लिए हो। यदि नहीं, तो इन चरणों से "व्यवस्था" खंड में विशिष्ट परीक्षणों के भीतर लिया जाता है।
निर्भरता से कैसे निपटें
कई बार एक वर्ग को अपने तरीकों को निष्पादित करने के लिए अन्य वर्गों की निर्भरता होती है। इन अन्य वर्गों पर निर्भर नहीं होने में सक्षम होने के लिए, आपको इन्हें नकली करना होगा। आप इन कक्षाओं को स्वयं बना सकते हैं या एक अलगाव या मॉकअप ढांचे का उपयोग कर सकते हैं। एक अलगाव ढांचा कोड का एक संग्रह है जो नकली कक्षाओं के आसान निर्माण को सक्षम बनाता है।
नकली कक्षाएं
कोई भी वर्ग जो इस बात का ढोंग करने के लिए पर्याप्त कार्यक्षमता प्रदान करता है कि यह CUT द्वारा अपेक्षित एक निर्भरता है। दो प्रकार के फेक हैं: स्टब्स और मोक्स।
- एक ठूंठ: एक नकली जो परीक्षण के पारित होने या विफल होने पर कोई प्रभाव नहीं पड़ता है और जो परीक्षण को चलाने की अनुमति देने के लिए विशुद्ध रूप से मौजूद है।
- एक नकली: एक नकली जो CUT के व्यवहार का ट्रैक रखता है और उस व्यवहार के आधार पर परीक्षा में उत्तीर्ण या विफल हो जाता है।
यूनिट परीक्षण क्यों करते हैं?
1. यूनिट परीक्षण में कीड़े मिलेंगे
जब आप परीक्षणों का एक पूरा सूट लिखते हैं जो यह निर्धारित करते हैं कि किसी दिए गए वर्ग के लिए अपेक्षित व्यवहार क्या है, तो ऐसा कुछ भी नहीं है जो अपेक्षा के अनुरूप व्यवहार नहीं कर रहा है।
2. यूनिट परीक्षण कीड़े को दूर रखेगा
एक बदलाव करें जो बग का परिचय देता है और आपके परीक्षण अगली बार जब आप अपने परीक्षण चलाते हैं, तो इसे प्रकट कर सकते हैं।
3. यूनिट परीक्षण समय बचाता है
इकाई परीक्षण लिखना यह सुनिश्चित करने में मदद करता है कि आपका कोड शुरुआत से ही सही तरीके से तैयार किया गया है। यूनिट परीक्षण परिभाषित करते हैं कि आपके कोड को क्या करना चाहिए और इस तरह आप समय लेखन कोड खर्च नहीं करेंगे जो ऐसा नहीं करता है। कोई भी कोड में जांच नहीं करता है कि वे कामों पर विश्वास नहीं करते हैं और आपको खुद को यह सोचने के लिए कुछ करना होगा कि यह काम करता है। इकाई परीक्षण लिखने के लिए उस समय को खर्च करें।
4. यूनिट टेस्टिंग से मानसिक शांति मिलती है
आप उन सभी परीक्षणों को चला सकते हैं और जान सकते हैं कि आपका कोड उसी तरह काम करता है जैसा कि माना जाता है। आपके कोड की स्थिति जानने के बाद, यह काम करता है, और यह कि आप बिना किसी डर के इसे अपडेट और सुधार कर सकते हैं, यह बहुत अच्छी बात है।
5. यूनिट परीक्षण एक वर्ग के उचित उपयोग के दस्तावेज
यूनिट परीक्षण सरल उदाहरण बन जाते हैं कि आपका कोड कैसे काम करता है, यह क्या करने की उम्मीद है और आपके कोड का परीक्षण करने के लिए उचित तरीके से उपयोग किया जाता है।
यूनिट परीक्षण के लिए सामान्य नियम
1. एक इकाई परीक्षण की संरचना के लिए, AAA नियम का पालन करें
व्यवस्था:
परीक्षण की जाने वाली चीज़ सेट करें। परीक्षा परिणाम के साथ-साथ अपेक्षित परिणाम के लिए चर, गुण और गुण।
अधिनियम: वास्तव में उस विधि को कॉल करें जिसका आप परीक्षण कर रहे हैं
ज़ोर:
यह पुष्टि करने के लिए परीक्षण ढांचे को कॉल करें कि आपके "अधिनियम" का परिणाम वह है जो अपेक्षित था।
2. अलगाव में उस समय एक चीज का परीक्षण करें
सभी वर्गों को अलगाव में परीक्षण किया जाना चाहिए। उन्हें मोक्स और स्टब्स के अलावा किसी और चीज पर निर्भर नहीं होना चाहिए। उन्हें अन्य परीक्षणों के परिणामों पर निर्भर नहीं होना चाहिए।
3. सरल "बीच में नीचे दाईं ओर" परीक्षण पहले लिखें
आपके द्वारा लिखा गया पहला परीक्षण सबसे सरल परीक्षण होना चाहिए। उन्हें वही होना चाहिए जो मूल रूप से और आसानी से उस कार्यक्षमता का वर्णन करें जो आप लिखने की कोशिश कर रहे हैं। फिर, एक बार उन परीक्षणों को पास करने के बाद, आपको अधिक जटिल परीक्षण लिखना शुरू करना चाहिए जो आपके कोड के किनारों और सीमाओं का परीक्षण करता है।
4. उन परीक्षणों को लिखें जो किनारों का परीक्षण करते हैं
एक बार मूल बातें जांचने के बाद और आपको पता चलता है कि आपकी बुनियादी कार्यक्षमता काम करती है, तो आपको किनारों का परीक्षण करना चाहिए। परीक्षणों का एक अच्छा सेट किसी दिए गए तरीके के बाहरी किनारों का पता लगाएगा।
उदाहरण के लिए:
- ओवरफ्लो होने पर क्या होता है?
- क्या होगा यदि मान शून्य या नीचे जाते हैं?
- क्या होगा यदि वे MaxInt या MinInt में जाते हैं?
- यदि आप 361 डिग्री का चाप बनाते हैं तो क्या होगा?
- यदि आप एक खाली स्ट्रिंग पास करते हैं तो क्या होता है?
- यदि एक स्ट्रिंग आकार में 2GB है तो क्या होगा?
5. सीमाओं के पार परीक्षण
यूनिट परीक्षण किसी दिए गए सीमा के दोनों किनारों का परीक्षण करना चाहिए। सीमाओं के पार जाना ऐसी जगहें हैं जहां आपका कोड विफल हो सकता है या अप्रत्याशित तरीके से प्रदर्शन कर सकता है।
6. यदि आप कर सकते हैं, तो पूरे स्पेक्ट्रम का परीक्षण करें
यदि यह व्यावहारिक है, तो अपनी कार्यक्षमता के लिए संभावनाओं के पूरे सेट का परीक्षण करें। यदि इसमें एक एनुमरेटेड प्रकार शामिल है, तो एन्यूमरेशन में प्रत्येक आइटम के साथ कार्यक्षमता का परीक्षण करें। हर संभावना का परीक्षण करना अव्यावहारिक हो सकता है, लेकिन यदि आप हर संभावना का परीक्षण कर सकते हैं, तो करें।
7. यदि संभव हो, तो हर कोड पथ को कवर करें
यह एक चुनौतीपूर्ण भी है, लेकिन यदि आपका कोड परीक्षण के लिए डिज़ाइन किया गया है, और आप एक कोड कवरेज टूल का उपयोग करते हैं, तो आप यह सुनिश्चित कर सकते हैं कि आपके कोड की प्रत्येक पंक्ति कम से कम एक बार इकाई परीक्षणों द्वारा कवर हो। हर कोड पथ को कवर करने की गारंटी नहीं होगी कि कोई कीड़े नहीं हैं, लेकिन यह निश्चित रूप से आपको कोड की प्रत्येक पंक्ति की स्थिति के बारे में बहुमूल्य जानकारी देता है।
8. एक बग को प्रकट करने वाले परीक्षण लिखें, फिर इसे ठीक करें
यदि आपको कोई बग मिलता है, तो एक परीक्षण लिखें जो इसे प्रकट करता है। फिर, आप आसानी से परीक्षण को डिबग करके बग को ठीक कर सकते हैं। फिर आपके पास यह सुनिश्चित करने के लिए एक अच्छा प्रतिगमन परीक्षण है कि यदि बग किसी भी कारण से वापस आता है, तो आपको तुरंत पता चल जाएगा। जब आप डिबगर में चलने के लिए एक सरल, सीधे आगे परीक्षण करते हैं, तो बग को ठीक करना बहुत आसान है।
यहां एक पक्ष लाभ यह है कि आपने अपना परीक्षण किया है। क्योंकि आपने परीक्षण को विफल देखा है और फिर जब आपने इसे पास होते देखा है, तो आप जानते हैं कि परीक्षण इस बात में मान्य है कि यह सही तरीके से काम करने के लिए सिद्ध हुआ है। यह इसे और भी बेहतर प्रतिगमन परीक्षण बनाता है।
9. प्रत्येक परीक्षा को एक दूसरे से स्वतंत्र करें
टेस्ट को कभी भी एक-दूसरे पर निर्भर नहीं होना चाहिए। यदि आपके परीक्षणों को एक निश्चित क्रम में चलाना है, तो आपको परीक्षणों को बदलने की आवश्यकता है।
10. प्रति परीक्षण एक मुखर लिखें
आपको प्रति परीक्षण एक जोर लिखना चाहिए। यदि आप ऐसा नहीं कर सकते हैं, तो अपने कोड को अपवर्तित करें ताकि आपके सेटअप और टियरडाउन घटनाओं का उपयोग पर्यावरण को सही ढंग से बनाने के लिए किया जाए ताकि प्रत्येक परीक्षण को व्यक्तिगत रूप से चलाया जा सके।
11. अपने परीक्षणों को स्पष्ट रूप से नाम दें। लंबे नामों से डरो मत
चूंकि आप प्रति परीक्षण एक जोर दे रहे हैं, इसलिए प्रत्येक परीक्षण बहुत विशिष्ट हो सकता है। इस प्रकार, लंबे, पूर्ण परीक्षण नामों का उपयोग करने से डरो मत।
एक लंबा पूरा नाम आपको यह जानने की अनुमति देता है कि परीक्षण क्या विफल रहा और वास्तव में परीक्षण क्या करने की कोशिश कर रहा था।
लंबे, स्पष्ट रूप से नामित परीक्षण भी आपके परीक्षणों का दस्तावेज बना सकते हैं। "DividedByZeroShouldThrowException" दस्तावेजों का परीक्षण वास्तव में वही करता है जब आप शून्य से विभाजित करने का प्रयास करते हैं तो कोड क्या करता है।
12. परीक्षण करें कि हर उठाया अपवाद वास्तव में उठाया जाता है
यदि आपका कोड एक अपवाद उठाता है, तो यह सुनिश्चित करने के लिए एक परीक्षण लिखें कि वास्तव में आपके द्वारा उठाया गया प्रत्येक अपवाद तब उठाया जाता है जब इसे माना जाता है।
13. CheckTrue या Assert.IsTrue के उपयोग से बचें
बूलियन स्थिति की जाँच से बचें। उदाहरण के लिए, इसके बजाय अगर दो चीजें चेकट्रेड या Assert.IsTrue के साथ समान हैं, तो जाँच करें, इसके बजाय CheckEquals या Assert.IsEqual का उपयोग करें। क्यों? होने के कारण:
CheckTrue (अपेक्षित, वास्तविक) यह कुछ इस तरह की रिपोर्ट करेगा: "कुछ परीक्षण विफल: उम्मीद सही थी लेकिन वास्तविक परिणाम गलत था।"
यह आपको कुछ नहीं बताता है।
CheckEquals (अपेक्षित, वास्तविक)
यह आपको कुछ इस तरह बताएगा: "कुछ परीक्षण विफल रहे: अपेक्षित 7 लेकिन वास्तविक परिणाम 3 था।"
जब आपका अपेक्षित मूल्य वास्तव में बूलियन स्थिति हो, केवल CheckTrue या Assert.IsTrue का उपयोग करें।
14. लगातार अपने परीक्षण चलाएं
कोड लिखते समय अपने परीक्षण चलाएं। आपके परीक्षण तेजी से चलने चाहिए, जिससे आप मामूली बदलावों के बाद भी उन्हें चला सकें। यदि आप अपनी सामान्य विकास प्रक्रिया के भाग के रूप में अपने परीक्षण नहीं चला सकते हैं तो कुछ गलत हो रहा है। यूनिट परीक्षण लगभग तुरंत चलने वाले हैं। यदि वे नहीं हैं, तो संभवतः यह है क्योंकि आप उन्हें अलगाव में नहीं चला रहे हैं।
15. हर स्वचालित निर्माण के हिस्से के रूप में अपने परीक्षण चलाएं
जैसे आप विकसित होते समय परीक्षण चला रहे हैं, वैसे ही वे भी आपकी निरंतर एकीकरण प्रक्रिया का एक अभिन्न अंग होना चाहिए। एक असफल परीक्षा का मतलब यह होना चाहिए कि आपका निर्माण टूट गया है। चलो परीक्षण में विफल नहीं होने दें। इसे एक विफलता मानें और इसे तुरंत ठीक करें।
C # में सरल इकाई परीक्षण का उदाहरण
इस उदाहरण के लिए हम एक साधारण कैलकुलेटर के योग विधि का परीक्षण करेंगे।
इस उदाहरण में हम एप्लिकेशन का परीक्षण करेंगे: ApplicationToTest। यह एक वर्ग है जिसका नाम कैल्क है। इस वर्ग में एक विधि सम () है।
Sum () इस तरह दिखता है:
public void Sum(int a, int b)
{
return a + b;
}
इस विधि का परीक्षण करने के लिए इकाई परीक्षण इस तरह दिखता है:
[Testclass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
//Arrange
ApplicationToTest.Calc ClassCalc = new ApplicationToTest.Calc();
int expectedResult = 5;
//Act
int result = ClassCalc.Sum(2,3);
//Assert
Assert.AreEqual(expectedResult, result);
}
}