unit testing यूनिट परीक्षण क्या है?




यूनिट टेस्ट क्या है (16)

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

mbUnit , NUnit , mbUnit , आदि वे उपकरण हैं जो परीक्षण लिखने में आपकी सहायता करते हैं।

मैंने एक विशिष्ट भाषा में इकाई परीक्षण के लिए 'कैसे' पूछने के कई सवाल देखे, लेकिन कोई सवाल नहीं 'क्या', 'क्यों' और 'कब' पूछता है।

  • यह क्या है?
  • यह मेरे लिए क्या करता है?
  • मुझे क्यों इसका उपयोग करना चाहिए?
  • मुझे इसका उपयोग कब करना चाहिए (जब भी नहीं)?
  • कुछ आम नुकसान और गलतफहमी क्या हैं

यूनिट परीक्षण कोड लिखने के बारे में है जो आपके एप्लिकेशन कोड का परीक्षण करता है।

नाम का यूनिट हिस्सा एक समय में कोड की छोटी इकाइयों (उदाहरण के लिए एक विधि) का परीक्षण करने के इरादे के बारे में है।

xUnit इस परीक्षण में मदद करने के लिए है - वे ढांचे हैं जो इसके साथ सहायता करते हैं। इसका एक हिस्सा स्वचालित परीक्षण धावक है जो आपको बताता है कि कौन सा परीक्षण विफल रहता है और कौन से पास होते हैं।

उनके पास सामान्य कोड सेट करने की सुविधा भी है जो आपको प्रत्येक परीक्षण में हाथ से पहले चाहिए और सभी परीक्षण समाप्त होने पर इसे फाड़ें।

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


मैं जेरार्ड मेस्ज़ारोस द्वारा एक्सयूनीट टेस्टिंग पैटर्न बुक की सिफारिश करना चाहता हूं। यह बड़ा है लेकिन इकाई परीक्षण पर एक महान संसाधन है। यहां उनकी वेबसाइट का एक लिंक है जहां उन्होंने यूनिट परीक्षण की मूल बातें पर चर्चा की। http://xunitpatterns.com/XUnitBasics.html


यूनिट परीक्षण, मोटे तौर पर बोल रहा है, परीक्षण कोड के साथ अलगाव में अपने कोड की बिट्स का परीक्षण। दिमाग में आने वाले तत्काल फायदे हैं:

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

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

यूनिट परीक्षण को देखने का एक और तरीका यह है कि आप पहले परीक्षण लिखते हैं। इसे टेस्ट-संचालित विकास (लघु अवधि के लिए टीडीडी) के रूप में जाना जाता है। टीडीडी अतिरिक्त फायदे लाता है:

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

यदि आप अब यूनिट परीक्षण नहीं कर रहे हैं, तो मैं आपको सलाह देता हूं कि आप इसे शुरू करें। एक अच्छी किताब प्राप्त करें, व्यावहारिक रूप से कोई भी xUnit-book करेगा क्योंकि अवधारणाएं उनके बीच बहुत अधिक हस्तांतरणीय हैं।

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

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


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

यह सबसे प्रभावी है जब सभी यूनिट परीक्षण स्वचालित रूप से चलाए जा सकते हैं।

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

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

कुछ टीमें अपने उपवर्तन भंडार से हुक लिखती हैं ताकि जब भी आप परिवर्तन करते हैं तो इकाई परीक्षण स्वचालित रूप से चलाए जाते हैं।

अपने यूनिट परीक्षण को उसी एप्लिकेशन में अपने आवेदन के रूप में रखना अच्छा अभ्यास है।


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


मैं दान से असहमत नहीं हूं (हालांकि एक बेहतर विकल्प सिर्फ जवाब देने के लिए नहीं हो सकता है ... लेकिन ...

यूनिट परीक्षण आपके सिस्टम के व्यवहार और कार्यक्षमता का परीक्षण करने के लिए कोड लिखने की प्रक्रिया है।

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

  1. यह सुनिश्चित करते हुए कि आप व्यवहार (रीफैक्टरिंग) नहीं बदलते हैं, तकनीकी कार्यान्वयन को बदलना आसान बनाएं। उचित रूप से यूनिट परीक्षण कोड को आक्रामक रूप से पुन: संसाधित / साफ किया जा सकता है, इसे ध्यान में रखे बिना कुछ तोड़ने का थोड़ा मौका।
  2. व्यवहार जोड़ने या फिक्स करने के दौरान डेवलपर्स को आत्मविश्वास दें।
  3. अपना कोड दस्तावेज करें
  4. अपने कोड के उन क्षेत्रों को इंगित करें जो कसकर युग्मित हैं। यूनिट टेस्ट कोड करना मुश्किल है जो कसकर युग्मित है
  5. अपने एपीआई का उपयोग करने के लिए साधनों को प्रदान करें और जल्दी ही कठिनाइयों की तलाश करें
  6. विधियों और वर्गों को इंगित करता है जो बहुत ही संयोजी नहीं हैं

आपको इकाई परीक्षण करना चाहिए क्योंकि यह आपके ग्राहक को एक रखरखाव योग्य और गुणवत्ता वाले उत्पाद को वितरित करने के लिए आपकी रूचि में है।

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

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

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


मैं समय बचाने के लिए यूनिट परीक्षण का उपयोग करता हूं।

जब व्यापार तर्क (या डेटा एक्सेस) परीक्षण कार्यक्षमता का निर्माण करना अक्सर कई स्क्रीनों में टाइपिंग सामान शामिल कर सकता है जो अभी तक समाप्त हो सकते हैं या नहीं भी हो सकते हैं। इन परीक्षणों को स्वचालित करने से समय बचाता है।

मेरे लिए यूनिट परीक्षण मॉड्यूलरिज्ड परीक्षण दोहन का एक प्रकार है। आम तौर पर कम से कम एक परीक्षण प्रति सार्वजनिक समारोह होता है। मैं विभिन्न व्यवहारों को कवर करने के लिए अतिरिक्त परीक्षण लिखता हूं।

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

मेरे लिए यह पता लगाने के लिए बहुत तेज़ है कि मेरा नया कोड कोड में जांच करने के लिए मेरे यूनिट परीक्षणों में कुछ तोड़ देता है और कुछ फ्रंट-एंड डेवलपर को कोई समस्या मिलती है।

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

यूनिट परीक्षण सभी परीक्षण आवश्यकताओं को हल करने में सक्षम नहीं होंगे। वे विकास के समय को बचाने और आवेदन के मुख्य भाग परीक्षण करने में सक्षम होंगे।


Testivus प्रयोग करें। आपको बस इतना जानने की ज़रूरत है :)


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

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

मैं अंत तक नहीं पहुंच पाया, क्योंकि मुझे नियमित-अब-दंड की आवश्यकता थी, लेकिन यह एक अच्छा अभ्यास था।


मुझे लगता है कि जिस बिंदु को आप समझ में नहीं आता है वह यह है कि यूनिट परीक्षण फ्रेमवर्क जैसे एनयूनीट (और जैसे) छोटे से मध्यम आकार के परीक्षणों को स्वचालित करने में आपकी सहायता करेंगे। आम तौर पर आप एक बटन पर क्लिक करके जीयूआई में परीक्षण चला सकते हैं (उदाहरण के लिए, NUnit के मामले में) और फिर - उम्मीद है - प्रगति पट्टी हरे रहें। यदि यह लाल हो जाता है, तो फ्रेमवर्क आपको दिखाता है कि कौन सा परीक्षण विफल हुआ और वास्तव में क्या गलत हुआ। एक सामान्य इकाई परीक्षण में, आप अक्सर assertions का उपयोग करते हैं, उदाहरण के लिए Assert.AreEqual(expectedValue, actualValue, "some description") - इसलिए यदि दो मान असमान हैं तो आपको "कुछ विवरण: अपेक्षित <अपेक्षित वैल्यू> कह रहा था" actualValue> "।

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


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

  1. टीडीडी का मतलब कोड की मात्रा से दोगुना लिखना नहीं है। टेस्ट कोड आमतौर पर लिखने के लिए काफी तेज़ और दर्द रहित होता है और यह आपकी डिजाइन प्रक्रिया का महत्वपूर्ण हिस्सा है और गंभीर रूप से।

  2. कोडिंग रोकने के लिए टीडीडी आपको यह समझने में मदद करता है! आपके परीक्षण आपको विश्वास दिलाते हैं कि आपने अभी पर्याप्त किया है और ट्विकिंग रोक सकते हैं और अगली चीज़ पर जा सकते हैं।

  3. बेहतर कोड प्राप्त करने के लिए परीक्षण और कोड एक साथ काम करते हैं। आपका कोड खराब / छोटी गाड़ी हो सकती है। आपका परीक्षण खराब / छोटी गाड़ी हो सकती है। टीडीडी में आप दोनों को खराब / छोटी गाड़ी होने की संभावना पर बैंकिंग कर रहे हैं। अक्सर यह परीक्षण जिसे फिक्सिंग की आवश्यकता होती है लेकिन यह अभी भी एक अच्छा परिणाम है।

  4. टीडीडी कोडिंग कब्ज के साथ मदद करता है। आप जानते हैं कि यह महसूस करने के लिए कि आपके पास इतना मुश्किल है कि आप कहां से शुरू करना चाहते हैं? शुक्रवार की दोपहर है, यदि आप बस कुछ और घंटों के लिए विलंब करते हैं ... टीडीडी आपको बहुत तेज़ी से मांस करने की इजाजत देता है जो आपको लगता है कि आपको क्या करने की ज़रूरत है, और आपका कोडिंग जल्दी से बढ़ रहा है। इसके अलावा, प्रयोगशाला चूहों की तरह, मुझे लगता है कि हम सभी उस बड़े हरे रंग की रोशनी का जवाब देते हैं और इसे फिर से देखने के लिए कड़ी मेहनत करते हैं!

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

  6. मुझे लगता है कि यह फाउलर था जिसने कहा: "असरदार परीक्षण, अक्सर चलते हैं, सही परीक्षणों से काफी बेहतर होते हैं जो कभी भी लिखे नहीं जाते हैं"। मैं इसे परीक्षण लिखने की अनुमति देने के रूप में व्याख्या करता हूं जहां मुझे लगता है कि वे सबसे उपयोगी होंगे, भले ही मेरा शेष कोड कवरेज अपूर्ण रूप से अधूरा हो।

  7. टीडीडी लाइन के नीचे सभी प्रकार के आश्चर्यजनक तरीकों से मदद करता है। अच्छा यूनिट परीक्षण दस्तावेज में मदद कर सकता है कि कुछ क्या करना है, वे आपको एक परियोजना से दूसरे प्रोजेक्ट में कोड माइग्रेट करने में मदद कर सकते हैं और आपको अपने गैर-परीक्षण सहयोगियों पर श्रेष्ठता की अनचाहे भावना दे सकते हैं :)

यह प्रस्तुति सभी स्वादिष्ट भलाई परीक्षणों के लिए एक उत्कृष्ट परिचय है।


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

यदि आप मैन्युअल रूप से अपने कोड का परीक्षण करते हैं, तो यह आपको विश्वास दिला सकता है कि कोड पूरी तरह से काम कर रहा है - इसकी वर्तमान स्थिति में । लेकिन एक हफ्ते बाद, जब आपने इसमें थोड़ा बदलाव किया? जब भी आप अपने कोड में कुछ भी बदलते हैं, तो क्या आप हाथ से फिर से इसे फिर से सहेजने के इच्छुक हैं? शायद शायद नहीं :-(

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

यह हाथ परीक्षण पर यूनिट परीक्षण का मुख्य लाभ है। लेकिन रुकिए, और भी है:

  • यूनिट परीक्षण नाटकीय रूप से विकास फीडबैक लूप को कम करते हैं : एक अलग परीक्षण विभाग के साथ आपको यह जानने के लिए सप्ताह लग सकते हैं कि आपके कोड में एक बग है, जिसके द्वारा आप पहले से ही अधिकतर संदर्भ भूल गए हैं, इस प्रकार आपको घंटे लग सकते हैं बग ढूंढें और ठीक करें; यूनिट परीक्षणों के साथ ओटीओएच, प्रतिक्रिया चक्र सेकंड में मापा जाता है, और बग फिक्स प्रक्रिया आम तौर पर "ओह sh * टी की रेखाओं के साथ होती है, मैं यहां उस स्थिति की जांच करना भूल गया" :-)
  • यूनिट परीक्षण आपके कोड के व्यवहार को प्रभावी ढंग से दस्तावेज (आपकी समझ) दस्तावेज करते हैं
  • यूनिट परीक्षण आपको अपने डिज़ाइन विकल्पों का पुनर्मूल्यांकन करने के लिए मजबूर करता है, जिसके परिणामस्वरूप सरल, क्लीनर डिज़ाइन होता है

यूनिट परीक्षण ढांचे, बदले में, आपके परीक्षणों को लिखना और चलाने में आसान बनाते हैं।


यह जवाब देता है कि आपको यूनिट परीक्षण क्यों करना चाहिए।

जावास्क्रिप्ट में कवर यूनिट परीक्षण के नीचे 3 वीडियो लेकिन सामान्य सिद्धांत अधिकांश भाषाओं में लागू होते हैं।

यूनिट परीक्षण: मिनट अब बाद में बचाएंगे - एरिक मान - https://www.youtube.com/watch?v=_UmmaPe8Bzc

जेएस यूनिट परीक्षण (बहुत अच्छा) - https://www.youtube.com/watch?v=-IYqgx8JxlU

लेखन योग्य जावास्क्रिप्ट - https://www.youtube.com/watch?v=OzjogCFO4Zo

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

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

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

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

जब आप पहली बार इस विषय को सुनते हैं और आप स्वयं को सोचते हैं, तो यह काफी उलझन में है, क्या मैं पहले से ही अपने कोड का परीक्षण नहीं कर रहा हूं? और जो कोड आपने लिखा है वह काम कर रहा है जैसे कि यह पहले से ही माना जाता है, "मुझे एक और ढांचे की आवश्यकता क्यों है?" ... हाँ आप पहले से ही अपने कोड का परीक्षण कर रहे हैं लेकिन कंप्यूटर ऐसा करने में बेहतर है। आपको केवल एक बार कोड के फ़ंक्शन / यूनिट के लिए पर्याप्त पर्याप्त परीक्षण लिखना होगा और बाकी को शक्तिशाली सीपीयू द्वारा आपके लिए ख्याल रखा जाएगा, इसके बजाय आपको मैन्युअल रूप से जांच करनी होगी कि जब आप कोई परिवर्तन करते हैं तो आपका सभी कोड अभी भी काम कर रहा है तुम्हारा कोड।

साथ ही, यदि आप नहीं चाहते हैं तो आपको अपने कोड का परीक्षण करने की आवश्यकता नहीं है, लेकिन यह आपकी परियोजना / कोड बेस को बड़े होने लगते हैं क्योंकि बग बढ़ने की संभावना बढ़ जाती है।


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

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

और अब आपको एक समस्या है: टूटा हुआ कोड ट्रंक में है और कोई भी जानता है। सबसे अच्छा मामला यह है कि एक आंतरिक परीक्षक आपको जहाज से पहले पाता है, लेकिन गेम में देर से कोड को ठीक करना महंगा है। और यदि कोई आंतरिक परीक्षक इसे नहीं ढूंढता है ... अच्छा, यह वास्तव में बहुत महंगा हो सकता है।

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


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

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

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

कहें कि आपके फ़ंक्शन ने डेटाबेस से कुछ संख्याएं पुनर्प्राप्त की हैं और फिर मानक विचलन गणना की है। आप यहां परीक्षण करने की कोशिश कर रहे हैं? मानक विचलन की गणना सही ढंग से की जाती है या डेटा डेटाबेस से वापस कर दिया जाता है?

एक इकाई परीक्षण में आप बस परीक्षण करना चाहते हैं कि मानक विचलन की गणना सही ढंग से की जाती है। एकीकरण परीक्षण में आप मानक विचलन गणना और डेटाबेस पुनर्प्राप्ति का परीक्षण करना चाहते हैं।







glossary