जवाबों:
दोनों मूल्यवान हैं। मैं सिद्धांत और नाक दोनों का उपयोग करता हूं जो एकमत की जगह लेते हैं। मैं उन मामलों के लिए सिद्धांत का उपयोग करता हूं जहां परीक्षण उपयोग का एक उदाहरण दे रहा है जो वास्तव में प्रलेखन के रूप में उपयोगी है। आम तौर पर मैं इन परीक्षणों को व्यापक नहीं बनाता, पूरी तरह से सूचनात्मक के लिए लक्ष्य। मैं प्रभावी रूप से रिवर्स में doctest का उपयोग कर रहा हूं: मेरे कोड का परीक्षण मेरे सिद्धांत के आधार पर सही नहीं है, लेकिन यह जांचने के लिए कि कोड के आधार पर मेरा प्रलेखन सही है।
कारण यह है कि मुझे लगता है कि व्यापक सिद्धांत आपके दस्तावेज़ को बहुत अधिक अव्यवस्थित कर देंगे, इसलिए आप या तो अनुपयोगी डोकस्ट्रिंग्स, या अपूर्ण परीक्षण के साथ समाप्त हो जाएंगे।
वास्तव में कोड का परीक्षण करने के लिए , लक्ष्य हर मामले को पूरी तरह से परखना है , उदाहरण के लिए क्या करता है, यह स्पष्ट करने के बजाय, जो एक अलग लक्ष्य है जो मुझे लगता है कि अन्य रूपरेखाओं से बेहतर है।
मैं लगभग विशेष रूप से unittest का उपयोग करता हूं।
एक बार थोड़ी देर में, मैं कुछ सामान को डॉक्टिंग में डाल दूंगा जो कि सबसे महत्वपूर्ण है।
परीक्षण के मामलों में से 95% एकतरफा हैं।
क्यों? मुझे डॉकस्ट्रिंग्स को कुछ हद तक कम और ज्यादा रखना पसंद है। कभी-कभी परीक्षण मामलों में एक डॉकस्ट्रिंग को स्पष्ट करने में मदद मिलती है। अधिकांश समय, एप्लिकेशन के परीक्षण के मामले डॉकस्ट्रिंग के लिए बहुत लंबे होते हैं।
docstringऔर क्या नहीं। मैं वास्तव में इस शब्द का docstring पसंद करता हूं कि यह स्पष्ट रूप से एक इंटरफ़ेस का उपयोग करने का तरीका दिखा रहा है, लेकिन इसके लिए इसका उपयोग करना और यूनिट परीक्षण दोनों अच्छी तरह से फिट नहीं हो सकते हैं।
मैं एक जैव सूचना विज्ञान के रूप में काम करता हूं, और मेरे द्वारा लिखे गए अधिकांश कोड "एक समय, एक कार्य" स्क्रिप्ट, कोड है जो केवल एक या दो बार चलाया जाएगा और यह एक विशिष्ट कार्य को निष्पादित करेगा।
इस स्थिति में, बड़े unittests लिखना ओवरकिल हो सकता है, और सिद्धांत एक उपयोगी समझौता हैं। वे लिखने के लिए तेज हैं, और चूंकि वे आमतौर पर कोड में शामिल होते हैं, वे हमेशा इस बात पर नजर रखने की अनुमति देते हैं कि कोड को कैसे व्यवहार करना चाहिए, बिना किसी अन्य फ़ाइल को खोलने के। छोटी स्क्रिप्ट लिखते समय यह उपयोगी है।
इसके अलावा, सिद्धांत तब उपयोगी होते हैं जब आपको अपनी स्क्रिप्ट किसी ऐसे शोधकर्ता को देनी होती है जो प्रोग्रामिंग में निपुण न हो। कुछ लोगों को यह समझना बहुत मुश्किल है कि कैसे unittests संरचित हैं; दूसरी ओर, सिद्धांत उपयोग के सरल उदाहरण हैं, इसलिए लोग उन्हें केवल कॉपी और पेस्ट करके देख सकते हैं कि उनका उपयोग कैसे करना है।
इसलिए, मेरे उत्तर को फिर से शुरू करने के लिए: सिद्धांत तब उपयोगी होते हैं जब आपको छोटी स्क्रिप्ट लिखनी होती है, और जब आपको उन्हें पास करना होता है या उन शोधकर्ताओं को दिखाना होता है जो कंप्यूटर वैज्ञानिक नहीं हैं।
यदि आप केवल इकाई परीक्षण के विचार से शुरू कर रहे हैं, तो मैं शुरू करूंगा doctestक्योंकि यह उपयोग करने के लिए बहुत सरल है। यह स्वाभाविक रूप से प्रलेखन के कुछ स्तर भी प्रदान करता है। और अधिक व्यापक परीक्षण के साथ doctest, आप परीक्षण को एक बाहरी फ़ाइल में रख सकते हैं ताकि यह आपके दस्तावेज़ को अव्यवस्थित न करे।
मैं unittestआपको सुझाव दूंगा कि यदि आप JUnit या कुछ समान उपयोग करने की पृष्ठभूमि से आ रहे हैं, जहां आप इकाई परीक्षण को आम तौर पर उसी तरह से लिखना चाहते हैं जैसे आप कहीं और कर रहे हैं।
doctestसाथ शुरू करने के लिए) प्रोत्साहित किया गया था , लेकिन अंततः इसे पछतावा हुआ। गैर-तुच्छ परीक्षण-मामलों के लिए, मैंने अपने संपादक के सिंटैक्स हाइलाइटिंग और ऑटो-समापन को खो दिया। जब परीक्षण एक अलग फ़ाइल में थे, तो मैं इसे संपादक से सीधे नहीं चला सकता था - मुझे हर बार संदर्भ को संबंधित स्रोत फ़ाइल में बदलना होगा।
मैं विशेष रूप से यूनीटेस्ट का उपयोग करता हूं; मुझे लगता है कि मुख्य मॉड्यूल को बहुत ज्यादा क्लैट करते हैं। यह शायद पूरी तरह से परीक्षण लिखने के साथ करना है।
दोनों का उपयोग करना एक वैध और सरल विकल्प है। doctestमॉड्यूल प्रदान करता है DoctTestSuiteऔरDocFileSuite तरीकों जो एक मॉड्यूल या फ़ाइल से क्रमशः एक unittest संगत testsuite पैदा करते हैं।
इसलिए मैं दोनों का उपयोग करता हूं और आमतौर पर उन कार्यों के साथ सरल परीक्षणों के लिए सिद्धांत का उपयोग करता हूं जिनके लिए बहुत कम या कोई सेटअप (तर्कों के लिए सरल प्रकार) की आवश्यकता होती है। मुझे वास्तव में लगता है कि कुछ सिद्धांत परीक्षण मदद करते हैं से कार्य करते हैं, बजाय इससे बचने के।
लेकिन अधिक जटिल मामलों के लिए, और परीक्षण मामलों के अधिक व्यापक सेट के लिए, मैं यूनीटेस्ट का उपयोग करता हूं जो अधिक नियंत्रण और लचीलापन प्रदान करता है।
मैं एकमत के लिए प्रतिस्थापन के रूप में सिद्धांत का उपयोग नहीं करता। हालांकि वे थोड़ा ओवरलैप करते हैं, दो मॉड्यूल में एक ही फ़ंक्शन नहीं है:
मैं unittestएक इकाई परीक्षण ढांचे के रूप में उपयोग करता हूं, जिसका अर्थ है कि यह मुझे बाकी कोड पर किसी भी संशोधन के प्रभाव को जल्दी से निर्धारित करने में मदद करता है।
मैं doctestएक गारंटी के रूप में उपयोग करता हूं कि टिप्पणियाँ (अर्थात डॉकस्ट्रिंग्स) अभी भी कोड के वर्तमान संस्करण के लिए प्रासंगिक हैं।
परीक्षण संचालित विकास का व्यापक रूप से प्रलेखित लाभ मुझे मिलता है unittest। doctestकोड के रखरखाव को गुमराह करने वाली पुरानी टिप्पणियों के कहीं अधिक सूक्ष्म खतरे को हल करता है।
मैं लगभग कभी मत का प्रयोग नहीं करता। मैं चाहता हूं कि मेरा कोड सेल्फ डॉक्यूमेंटिंग हो और डॉकस्ट्रिंग यूजर को डॉक्यूमेंटेशन मुहैया कराए। एक मॉड्यूल में परीक्षणों की सैकड़ों लाइनों को जोड़ने वाला IMO डॉकस्ट्रिंग्स को बहुत कम पठनीय बनाता है। मुझे जरूरत पड़ने पर संशोधित करने के लिए यूनिट परीक्षण भी आसान लगते हैं।
Doctestकुछ समय के लिए गलत परिणाम हो सकता है। खासतौर पर जब आउटपुट में एस्केप सीक्वेंस होते हैं। उदाहरण के लिए
def convert():
"""
>>> convert()
'\xe0\xa4\x95'
"""
a = '\xe0\xa4\x95'
return a
import doctest
doctest.testmod()देता है
**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
convert()
Expected:
'क'
Got:
'\xe0\xa4\x95'
**********************************************************************
1 items had failures:
1 of 1 in __main__.convert
***Test Failed*** 1 failures. इसके अलावा आउटपुट के प्रकार की जाँच नहीं करता है। यह सिर्फ आउटपुट स्ट्रिंग्स की तुलना करता है। उदाहरण के लिए इसने कुछ प्रकार को तर्कसंगत बनाया है जो पूर्णांक की तरह प्रिंट करता है यदि यह पूरी संख्या है। फिर मान लें कि आपके पास फ़ंक्शन है जो तर्कसंगत लौटाता है। यदि आउटपुट तर्कसंगत पूर्ण संख्या या पूर्णांक संख्या है तो, एक सिद्धांत भिन्न नहीं होगा।
r""" ... """पहली समस्या को ठीक करने के लिए कच्चे docstrings ( ) का उपयोग कर सकते हैं ।
'\\xe0\\xa4\\x95'अपने डॉकस्ट्रिंग में उपयोग करें।
मैं खोज आधारित प्रणालियों ("नाक" और "py.test" को पसंद करता हूं, पूर्व में वर्तमान में उपयोग कर रहा हूं)।
doctest अच्छा है जब परीक्षण एक दस्तावेज के रूप में भी अच्छा है, अन्यथा वे कोड को बहुत अधिक अव्यवस्थित करते हैं।