पसंदीदा पायथन यूनिट-परीक्षण ढांचा

Question

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

प्रमुख विकल्प मैं ऑनलाइन देखा है कर रहे हैं:

• py.test
• nose

चौखटे आप पसंद करते हैं, और क्यों करता है?

---

अद्यतन 10.12.2011: unittest में परीक्षण स्वत: खोज और कई नई सुविधाओं की हाल ही में इसके साथ (अजगर 2.7 और 3.2 में), IMHO यह कम समझ में एक बाहरी पुस्तकालय का उपयोग करने में आता है।

---

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

Answer 1

nose वास्तव में एक इकाई परीक्षण रूपरेखा नहीं है। यह एक परीक्षण धावक है और उस पर एक महान है। यह unittest, py.test या doctest का उपयोग करके बनाए गए परीक्षण चला सकता है।

इकाई परीक्षण ढांचे के लिए मेरी वरीयता मानक unittest मॉड्यूल (जिसे pyUnit भी कहा जाता है) है। यह अन्य xUnit ढांचे के समान है और बिना पाइथन पृष्ठभूमि के लोगों के लिए संबंधित है। Eclipse/PyDev

py.test पर इसके लिए बहुत अच्छा समर्थन भी है, मुझे सेटअप/टियरडाउन के कई स्तर बहुत भ्रमित लगता है। मुझे यह भी पता चलता है कि यह यूनिट परीक्षणों को पढ़ने के लिए अत्यधिक असंगठित और कठिन होता है।

doctest सरल चीजों के लिए ठीक है, लेकिन मुझे लगता है कि यह बहुत सीमित है और वास्तव में जटिल और अत्यधिक इंटरैक्टिव कोड के लिए स्केल नहीं करता है।

Answer 2

यदि आप अपने यूनिट परीक्षण को कोड के करीब रखना चाहते हैं तो हमेशा doctest होता है।

HTH

Answer 3

मैं मानक unittest का उपयोग करता हूं। सुनिश्चित नहीं है कि आप एक और शैली के साथ प्रभावी ढंग से परीक्षण कैसे लिखेंगे - शायद एक समारोह में प्रत्येक परीक्षण, लेकिन फिर आप सेटअप/टियरडाउन कैसे संभालेंगे?

Answer 4

unittest.TestCase एक कक्षा है। अपने स्वयं के ऐड-ऑन सुविधाओं के साथ इसे उपclass करने के लिए स्वतंत्र महसूस करें जो आपको "एक ही प्रभाव को प्राप्त करने के लिए कम लिखने" की अनुमति देता है।

Answer 5

नाक की सबसे अच्छी सुविधाओं में से एक इसकी प्लगइन प्रणाली है: उदाहरण के लिए कवरेज प्लगइन आपको दिखाता है कि आपका कोड कितना बेकार है।unittests के बहुत सारे लिखने के बाद यह अक्सर देखने के लिए कैसे अपने कोड के बहुत शामिल नहीं है चौंकाने वाला है ....

Answer 6

nose2 नाक अधिक्रमित किया है और जिसका अर्थ है कि आप विभिन्न मापदंडों के साथ एक ही दावे चला सकते हैं parameterized tests का समर्थन करता है। यह आपको बहुत कम कोड के साथ अधिक परिदृश्यों को कवर करने की अनुमति देता है।

Answer 7

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

Answer 8

दिलचस्प है कि किसी ने अभी तक py.test की रक्षा करने का उत्तर नहीं दिया है। testing-in-python mailing list पर यह काफी लोकप्रिय है, उदा। यह हालिया धागा "why do you use py.test?"। सबसे आम प्रतिक्रियाओं शामिल:

• वितरित परीक्षण के लिए आसान समर्थन
• अच्छा प्लगइन वास्तुकला
• आसान कथनों (बस assert x == 42, assertEqual() नहीं)
• funcargs (2,3 या 2.4 कहा जाता जुड़नार के बाद से, कुछ अलग करने के लिए क्या अन्य परीक्षण ढांचे कॉल फिक्स्चर)

Answer 9

मुझे लगता है कि यह वास्तव में पसंद का मामला है। मैंने सभी प्रमुख परीक्षण ढांचे का उपयोग किया है, यह नीचे आता है कि आपको लगता है कि कम कोडिंग के साथ काम करता है। उसने कहा, मैं भी सबसे अच्छा पसंद करते हैं।

लेकिन मैंने तब से पाइस्टेस्ट की खोज की है और कभी पीछे नहीं देखा है। मैं अभी भी कभी-कभी सबसे अच्छा उपयोग करता हूं लेकिन नई परियोजनाओं पर सबसे ज्यादा उपयोग करना पसंद करता हूं।

Answer 10

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

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

तो मैं कहूंगा कि विजेता संयोजन unittest के साथ py.test है।http://docs.python.org/library/unittest.html आप निर्माण में unittest मॉड्यूल की चर्चा करते हुए कर रहे हैं, या कुछ अन्य pyUnit: