एक परियोजना लेखन इकाई परीक्षण के कौन से हिस्सों में लगभग या वास्तव में असंभव है? डेटा प्राप्त करना? एफ़टीपी?यूनिट परीक्षण की बात आती है तो परीक्षण नहीं करना चाहिए?
यदि इस प्रश्न का उत्तर है तो% 100 कवरेज एक मिथक है, है ना?
Here मैं (haacked कुछ माइकल पंख के माध्यम से पाया का कहना है कि एक जवाब हो सकता है:
वे कहते हैं,
एक परीक्षण एक इकाई परीक्षण नहीं है अगर:
- यह डेटाबेस
- से बात करता है यह नेटवर्क
पर संचार करता है- यह छू लेती फाइल सिस्टम
- यह अपने अन्य इकाई के किसी भी रूप में एक ही समय में नहीं चल सकता परीक्षण
- आप (जैसे संपादन config फाइल के रूप में) अपने वातावरण इसे चलाने के लिए करने के लिए विशेष काम करने के लिए किया है।
फिर एक ही लेख में उनका कहना है कि:
आम तौर पर, इकाई परीक्षण छोटा होने की अपेक्षा की जाती है, वे एक विधि या तरीकों के एक जोड़े की बातचीत का परीक्षण करें। जब आप डेटाबेस, सॉकेट या फ़ाइल सिस्टम को अपने यूनिट परीक्षणों में एक्सेस करते हैं, तो वे वास्तव में उन तरीकों के बारे में नहीं हैं; वे उस अन्य सॉफ़्टवेयर के साथ आपके कोड के एकीकरण के बारे में हैं।
मैं इस से पूरी तरह से असहमत हूं। क्या होगा यदि डेटाबेस के आधार पर कोड refactored है? – Sklivvz
@ स्क्लीवाज़: यही इंटरफेस/अमूर्त वर्ग और नकली वस्तुएं हैं। यदि अच्छी तरह डिज़ाइन किया गया है और डेटाबेस को दोबारा संशोधित किया गया है तो प्रभावित वर्गों को केवल डेटाबेस में इंटरफ़ेस को खाते में ले जाने की आवश्यकता है। – Spoike
डेटा एक्सेस संभव है क्योंकि आप एक परीक्षण डेटाबेस सेट अप कर सकते हैं।
आम तौर पर 'अवांछित' सामान एफ़टीपी, ईमेल और बहुत आगे है। हालांकि, वे आमतौर पर ढांचे के वर्ग होते हैं जिन पर आप भरोसा कर सकते हैं और इसलिए यदि आप उन्हें एक अमूर्तता के पीछे छुपाते हैं तो परीक्षण करने की आवश्यकता नहीं है।
इसके अलावा, 100% कोड कवरेज अपने आप पर पर्याप्त नहीं है।
परीक्षण डेटाबेस के आधार पर टेस्ट नेटवर्किंग समस्याओं के कारण भी असफल हो सकते हैं, जब तक कि आप इन-मेमोरी डेटाबेस का जिक्र नहीं कर रहे हों। –
किसी को वास्तविक डेटा के साथ परीक्षण की वकालत करने के लिए खुशी हुई। हम आम तौर पर कुछ डेटा मॉक/स्टब करते हैं, लेकिन परीक्षण सुनिश्चित करने के लिए हमारे डेटाबेस का उपयोग करते हैं। –
लेकिन एक परीक्षण डेटाबेस से बात करना एकीकरण परीक्षण होगा, न कि इकाई परीक्षण ... क्या यह नहीं होगा? –
यदि कोड यूनिट परीक्षण के लिए आवश्यक राज्य स्थापित करने के लिए कोड को जांचने के लिए कोड से काफी जटिल हो जाता है तो मैं रेखा खींचता हूं, और कार्यक्षमता का परीक्षण करने के लिए एक और तरीका ढूंढता हूं। उस बिंदु पर आपको यह पूछना होगा कि यूनिट टेस्ट सही है आप कैसे जानते हैं!
वह 100% कवरेज मिथक है, जिसका मतलब यह नहीं है कि 80% कवरेज बेकार है। लक्ष्य, ज़ाहिर है, 100% है, और यूनिट परीक्षणों और फिर एकीकरण परीक्षणों के बीच, आप इसका संपर्क कर सकते हैं।
इकाई परीक्षण में असंभव क्या है पूरी तरह से अजीब चीजें जो आपके ग्राहक उत्पाद के साथ करेंगे, की भविष्यवाणी कर रहे हैं। एक बार जब आप अपने कोड के इन दिमाग-दबाने वाले विकृतियों को खोजना शुरू कर देते हैं, तो सुनिश्चित करें कि परीक्षण परीक्षण में उन्हें वापस परीक्षण करें।
कुछ भी जो बहुत बड़े और जटिल सेटअप की आवश्यकता है। आप ftp (क्लाइंट) का परीक्षण कर सकते हैं, लेकिन फिर आपको एक FTP सर्वर सेट अप करने की आवश्यकता है। यूनिट टेस्ट के लिए आपको एक पुन: उत्पन्न परीक्षण सेटअप की आवश्यकता है। यदि आप इसे प्रदान नहीं कर सकते हैं, तो आप इसका परीक्षण नहीं कर सकते हैं।
100% कोड कवरेज प्राप्त करना लगभग हमेशा अपर्याप्त है। इस पर कई संसाधन हैं।
इकाई परीक्षण के लिए कुछ भी असंभव नहीं है लेकिन हमेशा कम रिटर्न होते हैं। यूनिट टेस्ट चीजों के लिए यह मूल्यवान नहीं हो सकता है जो इकाई परीक्षण के लिए दर्दनाक हैं।
@GarryShutler
मैं एक नकली smtp सर्वर (समझदार) का उपयोग करके वास्तव में unittest ईमेल। सुनिश्चित करें कि आप आवेदन कोड सही है बनाता है:
http://maas-frensch.com/peter/2007/08/29/unittesting-e-mail-sending-using-spring/
कुछ ऐसा शायद अन्य सर्वरों के लिए किया जा सकता है। नहीं तो आप एपीआई उपहास करने के लिए सक्षम होना चाहिए ...
Btw: 100% कवरेज केवल शुरुआत है ... बस सब कोड वास्तव में बढ़त मामलों आदि के बारे में कुछ भी नहीं है कि सेम एक बारमार डाला .... इसका मतलब है
एफ़टीपी, ईमेल और आगे आप सर्वर अनुकरण के साथ परीक्षण कर सकते हैं। यह मुश्किल है लेकिन संभव है।
परीक्षण योग्य कुछ त्रुटि प्रबंधन नहीं हैं। प्रत्येक कोड में त्रुटि प्रबंधन होता है जो कभी नहीं हो सकता है। उदाहरण के लिए जावा में कई अपवादों को पकड़ना चाहिए क्योंकि यह एक इंटरफ़ेस का हिस्सा है। लेकिन इस्तेमाल किया उदाहरण इसे कभी फेंक नहीं देगा। या स्विच के डिफ़ॉल्ट मामले यदि सभी संभावित मामलों के लिए केस ब्लॉक मौजूद है।
बेशक कुछ आवश्यक त्रुटि प्रबंधन को हटाया जा सकता है। लेकिन क्या भविष्य में कोडिंग त्रुटि है तो यह खराब है।
आप परीक्षण नहीं करेंगे? कुछ भी जो संभवतः तोड़ नहीं सकता है।
जब कोड कवरेज की बात आती है तो आप वास्तव में लिखने वाले 100% कोड का लक्ष्य रखना चाहते हैं - आपको तीसरे पक्ष के लाइब्रेरी कोड या ऑपरेटिंग सिस्टम कोड का परीक्षण करने की आवश्यकता नहीं है क्योंकि उस कोड को आपके परीक्षण के लिए वितरित किया जाएगा । जब तक यह नहीं। इस मामले में आप इसका परीक्षण करना चाहेंगे। या यदि ज्ञात बग हैं, तो आप किस मामले में बग की उपस्थिति के लिए परीक्षण करना चाहेंगे, ताकि आपको तय होने पर अधिसूचना मिल सके।
"आप क्या परीक्षण नहीं करेंगे? कुछ भी जो संभवतः तोड़ नहीं सकता है।" जाहिर है, ऐसी चीजें मौजूद नहीं हैं;) – Thomas
मुझे लगता है कि सामान जो संभवतः तोड़ नहीं सकता है वह है जहां त्रुटियों को ढूंढना सबसे मुश्किल है। मुझे आश्चर्य है क्योंकि? –
स्थिर! मैं बस पारंपरिक Agile सोच उद्धृत कर रहा हूँ: संभवतः तोड़ सकता है कि सब कुछ टेस्ट। एक्सेसर्स की तरह चीजें 'अटूट' मानी जाती हैं, इसलिए स्पष्ट परीक्षण की कोई आवश्यकता नहीं होती है, वे किसी और परीक्षण के दौरान परीक्षण करते हैं। – quamrana
अधिकांश परीक्षण, जिनमें भारी और महंगी (संसाधन या गणना समय की लागत) सेटअप की आवश्यकता होती है, एकीकरण परीक्षण होते हैं। यूनिट परीक्षण (सिद्धांत में) केवल कोड की छोटी इकाइयों का परीक्षण करना चाहिए। व्यक्तिगत कार्य
उदाहरण के लिए, यदि आप ईमेल-कार्यक्षमता का परीक्षण कर रहे हैं, तो यह एक नकली मेलर बनाने के लिए समझ में आता है। उस नकली का उद्देश्य यह सुनिश्चित करना है कि आपका कोड मेलर को सही तरीके से कॉल करता है। यह देखने के लिए कि आपका एप्लिकेशन वास्तव में मेल भेजता है, एकीकरण परीक्षण है।
यूनिट-परीक्षण और एकीकरण परीक्षणों के बीच अंतर बनाने के लिए यह बहुत उपयोगी है। यूनिट-टेस्ट बहुत तेजी से चलना चाहिए। आपके कोड में चेक करने से पहले अपने सभी यूनिट-परीक्षणों को चलाने के लिए आसानी से संभव होना चाहिए।
हालांकि, यदि आपके टेस्ट-सूट में कई एकीकरण परीक्षण होते हैं (जो सेट अप और डेटाबेस को फाड़ते हैं), तो आपका टेस्ट-रन आसानी से आधे घंटे से अधिक हो सकता है। उस स्थिति में यह बहुत संभावना है कि एक डेवलपर चेक-इन करने से पहले सभी यूनिट-टेस्ट नहीं चलाएगा।
तो अपने प्रश्न का उत्तर देने के लिए: नेट यूनिट-टेस्ट चीजें करें, जिन्हें एकीकरण परीक्षण के रूप में बेहतर ढंग से कार्यान्वित किया जाता है (और गेटटर/सेटर का परीक्षण भी न करें - यह समय बर्बाद है ;-))।
पहली जगह इकाई परीक्षण कोड का मुख्य कारण आपके कोड के डिज़ाइन को सत्यापित करना है। 100% कोड कवरेज हासिल करना संभव है, लेकिन नकली वस्तुओं या अलगाव या निर्भरता इंजेक्शन के कुछ रूपों के बिना नहीं।
याद रखें, यूनिट परीक्षण उपयोगकर्ताओं के लिए नहीं हैं, वे डेवलपर्स के लिए हैं और रिलीज से पहले सिस्टम को प्रमाणित करने के लिए सिस्टम बनाने के लिए उपयोग करते हैं। इसके लिए, यूनिट परीक्षणों को बहुत तेजी से चलना चाहिए और जितना संभव हो उतना कम कॉन्फ़िगरेशन और निर्भरता घर्षण होना चाहिए। जितना हो सके उतना करने की कोशिश करें, और परीक्षण से नेटवर्क कनेक्शन का उपयोग करने से बचें।
आप उनका परीक्षण कर सकते हैं, लेकिन वे यूनिट परीक्षण नहीं होंगे। यूनिट टेस्ट ऐसा कुछ है जो तारों को पार करने, डेटाबेस को मारने, किसी तीसरे पक्ष के साथ चलने/बातचीत करने, किसी अनचाहे/विरासत कोडेबेस इत्यादि को छूने,
इससे परे कुछ भी एकीकरण परीक्षण है।
शीर्षक में प्रश्न का स्पष्ट उत्तर यह है कि आपको इकाई को अपने एपीआई के आंतरिक परीक्षणों का परीक्षण नहीं करना चाहिए, आपको किसी और के व्यवहार पर भरोसा नहीं करना चाहिए, आपको किसी भी चीज का परीक्षण नहीं करना चाहिए जिसके लिए आप ज़िम्मेदार नहीं हैं।
शेष केवल आपके कोड को लिखने में सक्षम बनाने के लिए पर्याप्त होना चाहिए, अधिक नहीं, कम नहीं।
एक बड़ी परियोजना पर काम करते समय निश्चित 100% कवरेज अच्छा लक्ष्य है, लेकिन तैनाती से पहले एक या दो बग फिक्स करने वाली अधिकांश परियोजनाओं के लिए संपूर्ण यूनिट परीक्षण बनाने के लिए आवश्यक समय नहीं है।
एक बहुत ही विस्तृत स्तर पर फ़ॉर्म सबमिशन, डेटाबेस एक्सेस, एफ़टीपी एक्सेस इत्यादि जैसी चीजों का परीक्षण करना अक्सर समय की बर्बादी होती है; जब तक कि लिखे जाने वाले सॉफ़्टवेयर को उच्च स्तर की विश्वसनीयता (99.9 99% सामान) की आवश्यकता नहीं होती है, यूनिट परीक्षण बहुत ज्यादा हो सकता है और वास्तविक समय सिंक हो सकता है।
एक जीयूआई का यूनिट परीक्षण भी मुश्किल है, हालांकि मुझे लगता है कि असंभव नहीं है।
ऐसे कुछ उपकरण हैं जो जीयूआई के स्वचालित परीक्षण करते हैं, हालांकि मैंने स्वयं का उपयोग नहीं किया है। – rlerallut
यूनिट परीक्षण में, आपको ऐसी किसी भी चीज का परीक्षण नहीं करना चाहिए जो आपकी इकाई से संबंधित न हो; उनके संदर्भ में परीक्षण इकाइयां एक अलग मामला है। यह सरल जवाब है।
मैं जिस मूल नियम का उपयोग करता हूं वह यह है कि आपको यूनिट की अपनी इकाई की सीमाओं को छूने वाली किसी भी चीज का परीक्षण करना चाहिए (आमतौर पर कक्षा, या जो भी आपकी इकाई हो सकती है), और बाकी का मज़ाक उड़ाएं। कुछ डेटाबेस क्वेरी लौटने वाले परिणामों की जांच करने की कोई आवश्यकता नहीं है, यह जांचने के लिए पर्याप्त है कि आपकी इकाई सही क्वेरी को थूकती है।
इसका मतलब यह नहीं है कि आपको उन चीजों को छोड़ना नहीं चाहिए जो परीक्षण करना मुश्किल है; यहां तक कि अपवाद हैंडलिंग और समवर्ती मुद्दों का भी सही उपकरण का उपयोग करके बहुत अच्छी तरह से परीक्षण किया जा सकता है।
"यूनिट परीक्षण की बात आती है तो परीक्षण नहीं करना चाहिए?" * केवल गेटर्स और सेटर्स के साथ बीन्स। तर्क: आमतौर पर समय की बर्बादी जो कुछ और परीक्षण करने में बेहतर खर्च कर सकती है।
लक्ष्य 100% कोड कवरेज नहीं है और न ही यह 80% कोड कवरेज है। एक यूनिट परीक्षण लिखने में आसान नहीं है इसका मतलब यह नहीं है कि आपको इसे लिखना चाहिए, और यूनिट परीक्षण लिखने में कठोर होना मतलब यह नहीं है कि आपको प्रयास से बचना चाहिए।
किसी भी परीक्षण का लक्ष्य उपयोगकर्ता को दिखाई देने वाली समस्याओं को सबसे आक्रामक तरीके से पहचानना है।
विशिष्ट परीक्षण कैच की समस्याओं के लायक परीक्षण (झूठी सकारात्मक सहित) द्वारा ध्वजांकित समस्याओं को संलेखन, रखरखाव और निदान करने की कुल लागत क्या है?
यदि परीक्षण कैच की समस्या 'महंगी' है तो आप यह जांचने के लिए प्रयास कर सकते हैं कि इसका परीक्षण कैसे किया जाए और उस परीक्षण को बनाए रखा जाए। यदि परीक्षण कैच की समस्या छोटी है तो परीक्षण (और बनाए रखना!) परीक्षण (यहां तक कि कोड परिवर्तन की उपस्थिति में) बेहतर हो सकता है।
इकाई परीक्षण का मुख्य लक्ष्य देवताओं को कार्यान्वयन त्रुटियों से बचाने के लिए है। अकेले ही यह संकेत देना चाहिए कि बहुत अधिक प्रयास बर्बाद हो जाएगा। एक निश्चित बिंदु के बाद सही कार्यान्वयन के लिए बेहतर रणनीतियां हैं। इसके अलावा एक निश्चित बिंदु के बाद उपयोगकर्ता दृश्य समस्याएं गलत चीज़ को सही ढंग से कार्यान्वित करने के कारण होती हैं जिसे केवल उपयोगकर्ता स्तर या एकीकरण परीक्षण द्वारा पकड़ा जा सकता है।
मैं तीसरे पक्ष के कोड का परीक्षण न करने के बारे में quamrana की प्रतिक्रिया से असहमत हूं। यह एक यूनिट परीक्षण का आदर्श उपयोग है। यदि पुस्तकालय की एक नई रिलीज में बग (ओं) पेश किए जाते हैं तो क्या होगा? आदर्श रूप में, जब एक नया संस्करण तृतीय-पक्ष लाइब्रेरी जारी की जाती है, तो आप यूनिट परीक्षण चलाते हैं जो इस लाइब्रेरी के अपेक्षित व्यवहार का प्रतिनिधित्व करते हैं ताकि यह सत्यापित किया जा सके कि यह अभी भी अपेक्षित कार्य करता है।
एकीकरण परीक्षणों को पकड़ना नहीं चाहिए? वैसे भी, आपके तीसरे पक्ष के विक्रेता कौन हैं? आप उन्हें अपने स्वयं के कोड की जांच करने के लिए भरोसा नहीं करते हैं? निश्चित बग्स फिसल सकते हैं, लेकिन अगर वे अपने परीक्षणों के साथ एक बग चूक गए हैं, तो आपके परीक्षण शायद बग को भी याद करेंगे। (जब तक कि आप ईश्वरीय नहीं हैं या वे सिर्फ चूसते हैं) यदि आप अपने कोड का परीक्षण करना चाहते हैं तो आप अपने विक्रेताओं को क्या भुगतान कर रहे हैं? – dss539
@ dss539: थर्ड-पार्टी विक्रेता किसी भी अन्य विकास दबाव के अधीन हैं। यदि आपकी व्यावसायिक एप्लिकेशन की लाइन तीसरे पक्ष के पुस्तकालयों पर निर्भर करती है, तो क्या आपको नहीं लगता कि परीक्षण करके इस जोखिम को माइग्रेट करना समझदार हो सकता है ?? –
और भी कुछ जवाब एक और सवाल से निकाला जा सकता है (What makes a good unit test?) जवाब ...
विन्यास एक और आइटम है कि इकाई परीक्षण में अच्छी तरह से परीक्षण करने के लिए बहुत मुश्किल है। एकीकरण परीक्षण और अन्य परीक्षण विन्यास के खिलाफ किया जाना चाहिए। इससे परीक्षण की अनावश्यकता कम हो जाती है और बहुत समय लगता है। यूनिट टेस्ट कॉन्फ़िगरेशन की कोशिश करना अक्सर बेकार है।
जो भी पूरी तरह से निर्धारिती नहीं है वह यूनिट परीक्षण के लिए नो-नो है। आप चाहते हैं कि आपके यूनिट परीक्षण हमेशा प्रारंभिक स्थितियों के साथ पास या असफल हो जाएं - अगर थ्रेडिंग, या यादृच्छिक डेटा पीढ़ी, या समय/तिथियां, या बाहरी सेवाओं जैसे अजीबता इससे प्रभावित हो सकती हैं, तो आपको इसे अपने यूनिट परीक्षणों में शामिल नहीं करना चाहिए । समय/तिथियां एक विशेष रूप से बुरा मामला है। आप वर्तमान दिनांक और समय पर कार्यक्षमता पर भरोसा करने के बजाय इंजेक्शन (कोड और परीक्षण द्वारा) इंजेक्शन के साथ काम करने की तारीख रखने के लिए आमतौर पर आर्किटेक्ट कोड कर सकते हैं।
हालांकि कहा गया है कि यूनिट परीक्षण आपके आवेदन में परीक्षण का एकमात्र स्तर नहीं होना चाहिए। 100% यूनिट परीक्षण कवरेज प्राप्त करना अक्सर समय की बर्बादी है, और जल्दी से कम रिटर्न मिलता है।
सुदूर बेहतर सुनिश्चित करें कि सिस्टम ठीक से काम करता उच्च स्तर कार्यात्मक परीक्षण, और यहां तक कि एकीकरण परीक्षणों का एक सेट है करने के लिए है "एक बार यह सब में शामिल हो गए है" - जो परिभाषा द्वारा इकाई परीक्षण परीक्षण नहीं है।
Pex - Automated Whitebox Testing for .NET की कोशिश करता 100% कवरेज प्राप्त करने के लिए
एफ़टीपी, एसएमटीपी, आई/सामान्य रूप में हे ऐसे इंटरफेस का इस्तेमाल परीक्षण किया जाना चाहिए। इंटरफ़ेस को एडाप्टर (वास्तविक कोड के लिए) और इकाई परीक्षण के लिए एक नकली द्वारा कार्यान्वित किया जाना चाहिए।
कोई यूनिट परीक्षण वास्तविक बाहरी संसाधन (एफ़टीपी सर्वर इत्यादि) का उपयोग नहीं करना चाहिए
यह डुप्लिकेट के रूप में क्यों बंद नहीं किया गया था? http://stackoverflow.com/questions/62625/how-do-you-now-what-to-test-when-writing-unit-tests, http://stackoverflow.com/questions/61400/what-makes- एक-अच्छा-इकाई-परीक्षण, आदि – raven
मुझे लगता है कि उन तीन प्रश्न अलग हैं, और विभिन्न पृष्ठों पर चर्चा की जानी चाहिए। – spinodal
100% कोड कवरेज मिथक नहीं है, यह एक एसिम्पटोट है। – James