परीक्षण। शुरुआत

नमस्कार। इस पोस्ट की श्रृंखला में मैं अजगर में परीक्षण कोड के बारे में बात करने की कोशिश करूंगा, विशेष रूप से django परियोजनाओं में। हम इकाई परीक्षण (यूनिट परीक्षण), स्थिर कोड विश्लेषण और वेबसाइट परीक्षण के कुछ नुकसान देखेंगे।

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

unittest

यूनिट परीक्षणों को लागू करने के लिए मानक मॉड्यूल (unittest, पहले प्यूनिट) पायथन संस्करण 2.1 में दिखाई दिया और जावा के साथ एक JUnit पोर्ट था (यहां तक ​​कि कैमलकेस ने नामकरण को छोड़ दिया, जो pep8 के विपरीत था)। अजगर 2.7 (3.2) में, यूनीटेस्ट ने कई नई दिलचस्प चीजें @skip : अतिरिक्त जांच ( assert* ), सज्जाकार जो आपको एक अलग परीक्षण ( @skip , @skipIf ) को छोड़ देते हैं या टूटे हुए परीक्षणों को इंगित करते हैं जो डेवलपर के बारे में ( @expectedFailure ) तरीके से बदल गया है। कमांड लाइन से लॉन्च। अजगर 2.4 और उच्चतर के लिए इन परिवर्तनों के लिए एक बंदरगाह भी है, जिसे यूनिटेस्ट 2 कहा जाता है।

यह बात कैसे काम करती है मान लें कि हमारे पास एक अमानवीय रूप से जटिल मॉड्यूल है, run_once.py:

 def run_once(f): """ .    . """ def _f(*args, **kwargs): if not hasattr(_f, "_retval"): _f._retval = f(*args, **kwargs) return _f._retval return _f 

_{(यह एक डेकोरेटर है जो पैरामीटर फ़ंक्शन के पहले कॉल के परिणाम को बचाता है और हमेशा संग्रहीत मान लौटाता है।)}

हमारे मॉड्यूल का परीक्षण कुछ इस तरह दिख सकता है:

 import unittest class Test(unittest.TestCase): def test_run_once(self): @run_once def inc(n): return n + 1 #     inc()... self.assertEqual(inc(7), 8) # ...  --   self.assertEqual(inc(0), 8) if __name__ == "__main__": unittest.main() 

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

 $ python run_once.py 

और परीक्षा परिणाम देखें:

 . --- Ran 1 test in 0.000s OK 

doctest

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

 def run_once(f): """ >>> @run_once ... def foo(n): return n + 1 >>> foo(7) 8 >>> foo(0) 8 """ def _f(*args, **kwargs): if not hasattr(_f, "_retval"): _f._retval = f(*args, **kwargs) return _f._retval return _f if __name__ == "__main__": import doctest doctest.testmod() 

प्रारंभ कुंजी:

 $ python run_once2.py -v Trying: @run_once def foo(n): return n + 1 Expecting nothing ok Trying: foo(7) Expecting: 8 ok Trying: foo(0) Expecting: 8 ok 1 items had no tests: __main__ 1 items passed all tests: 3 tests in __main__.run_once 3 tests in 2 items. 3 passed and 0 failed. Test passed. 

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

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

py.test

अजगर के मानक पैकेज में शामिल उपकरणों के साथ, वैकल्पिक उपकरण हैं, उदाहरण के लिए, py.test । स्थापना हमेशा की तरह है

 easy_install -U pytest #  pip install -U pytest 

पहले उदाहरण से फ़ंक्शन को लें। संशोधित इकाई परीक्षण कुछ इस तरह दिखाई देगा:

 def test_run_once(): @run_once def inc(n): return n + 1 #     inc()... assert inc(7) == 8 # ...  --   assert inc(0) == 8 

आइए जाने:

 $ py.test run_once3.py === test session starts === platform darwin -- Python 2.6.1 -- pytest-2.0.3 collected 1 items run_once3.py . === 1 passed in 0.01 seconds === 

Py.test (अच्छा) की मुख्य विशेषताएं: कोई एपीआई (निष्पक्षता में: असाधारण मामलों में, एपीआई की अभी भी जरूरत है, लेकिन यह बहुत छोटा है); परख के माध्यम से जाँच करता है। यह गणना के बिना उत्पादन सर्वर पर, उदाहरण के लिए, py.test स्थापित किए बिना भी परीक्षण चलाने की क्षमता प्रदान करता है। टेस्ट को कक्षाओं के रूप में जारी किया जा सकता है ( test_* शैली में), या केवल फॉर्म test_* ।

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

नाक

नाक unittest के माध्यम से परीक्षण चलाने के लिए एक उपकरण है (और doctest, --with-doctest the --with-doctest )। इसका अपना API भी है, जो वैकल्पिक है। उपरोक्त सभी उदाहरणों को सफलतापूर्वक पूरा करता है:

 $ nosetests * -v --with-doctest test_run_once (run_once.Test) ... ok Doctest: run_once2.run_once ... ok run_once3.test_run_once ... ok --- Ran 3 tests in 0.008s OK 

जैसा कि Yur4eg सुझाव देता है (धन्यवाद!), नाक स्वतः फॉर्म test_* की फाइलों से परीक्षण एकत्र करता है, यदि वह एक है तो परीक्षण फ़ोल्डर को देखने के लिए पर्याप्त स्मार्ट है, यह --with-coverage ( --with-coverage ) का उपयोग करके कोड कवरेज को माप सकता है । आप केवल उन परीक्षणों को भी चला सकते हैं जो अंतिम रन (- बंद) में गिर गए थे।

मैं सिम के लिए अपनी छुट्टी ले रहा हूं। यह केवल उदाहरणों के स्रोत कोड को संलग्न करने के लिए रहता है, तीन टुकड़े। सार्वजनिक डोमेन।

अगले अंक में : नियमित django टेस्टिंग टूल और उनसे कैसे निपटें।