पायथन के साथ पायथन परीक्षण। पाइस्टेस्ट, अध्याय 1 के साथ शुरुआत करना

पीछे अगला

मैंने पाया कि पाइस्टेस्ट के साथ पायथन परीक्षण पाइस्टेस्ट परीक्षण वातावरण के लिए एक अत्यंत उपयोगी परिचयात्मक मार्गदर्शिका है। यह पहले से ही मुझे मेरी कंपनी में लाभांश लाता है।

क्रिस शेवर
VP of Product, Uprising Technology

इस पुस्तक में उदाहरण Python 3.6 और pytest 3.2 का उपयोग करके लिखे गए हैं। पाइस्टेस्ट 3.2 पायथन 2.6, 2.7, और पायथन 3.3+ का समर्थन करता है।

टास्क परियोजना के लिए स्रोत कोड, साथ ही साथ इस पुस्तक में दिखाए गए सभी परीक्षणों के लिए, पुस्तक के वेब पेज pragprog.com पर लिंक पर उपलब्ध है। परीक्षण कोड को समझने के लिए आपको स्रोत कोड डाउनलोड करने की आवश्यकता नहीं है; परीक्षण कोड उदाहरणों में एक सुविधाजनक रूप में प्रस्तुत किया गया है। लेकिन परियोजना के कार्यों के साथ पालन करने के लिए, या अपनी खुद की परियोजना का परीक्षण करने के लिए परीक्षण उदाहरणों को अनुकूलित करें (आपके हाथ अनटूट हो गए हैं!), आपको पुस्तक के वेब पेज पर जाना होगा और काम डाउनलोड करना होगा। वहाँ, पुस्तक के वेब पेज पर, इरेटा संदेशों और एक चर्चा मंच के लिए एक लिंक है।

स्पॉइलर के तहत इस श्रृंखला के लेखों की एक सूची है।

चलो चलते हैं

यह परीक्षण है:

ch1 / test_one.py

def test_passing(): assert (1, 2, 3) == (1, 2, 3) 

स्टार्टअप पर यह कैसा दिखता है:

 $ cd /path/to/code/ch1 $ pytest test_one.py ===================== test session starts ====================== collected 1 items test_one.py . =================== 1 passed in 0.01 seconds =================== 

Test_one.py के बाद डॉट का मतलब है कि एक परीक्षण चलाया गया था और यह पारित हो गया। यदि आपको अधिक जानकारी चाहिए, तो आप -v या --verbose उपयोग कर सकते हैं:

 $ pytest -v test_one.py ===================== test session starts ====================== collected 1 items test_one.py::test_passing PASSED =================== 1 passed in 0.01 seconds =================== 

यदि आपके पास एक रंग टर्मिनल है, तो PASSED और निचला रेखा हरा है। वाह!

यह एक असफल परीक्षा है:

ch1 / test_two.py

 def test_failing(): assert (1, 2, 3) == (3, 2, 1) 

जिस तरह से पाइस्टेस्ट टेस्ट फेलियर दिखाता है, कई कारणों में से एक है कि डेवलपर्स पाइस्ट को क्यों पसंद करते हैं। आइये देखते हैं क्या आता है:

 $ pytest test_two.py ===================== test session starts ====================== collected 1 items test_two.py F =========================== FAILURES =========================== _________________________ test_failing _________________________ def test_failing(): > assert (1, 2, 3) == (3, 2, 1) E assert (1, 2, 3) == (3, 2, 1) E At index 0 diff: 1 != 3 E Use -v to get the full diff test_two.py:2: AssertionError =================== 1 failed in 0.04 seconds =================== 

बहुत बढ़िया! परीक्षण परीक्षण test_failing हमें यह दिखाने के लिए कि यह असफल क्यों हुआ, इसका खंड मिलता है।

और सबसे सटीक रिपोर्ट करता है कि पहला क्रैश: इंडेक्स 0 एक बेमेल है।

इस संदेश का एक बड़ा हिस्सा लाल है, जो वास्तव में बाहर खड़ा है (यदि आपके पास रंग टर्मिनल है)।

यह पहले से ही बहुत सारी जानकारी है, लेकिन एक संकेत के साथ एक पंक्ति है जो उपयोग -v को मतभेदों के और भी अधिक विवरण प्राप्त करने के लिए कहती है।

चलो इस एक -v :

 $ pytest -v test_two.py ===================== test session starts ====================== collected 1 items test_two.py::test_failing FAILED =========================== FAILURES =========================== _________________________ test_failing _________________________ def test_failing(): > assert (1, 2, 3) == (3, 2, 1) E assert (1, 2, 3) == (3, 2, 1) E At index 0 diff: 1 != 3 E Full diff: E - (1, 2, 3) E ? ^ ^ E + (3, 2, 1) E ? ^ ^ test_two.py:2: AssertionError =================== 1 failed in 0.04 seconds =================== 

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

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

लेकिन पहले मुझे माफी मांगनी होगी। सॉरी assert (1, 2, 3) == (3, 2, 1) का परीक्षण करने के लिए क्षमा करें, यह बहुत उबाऊ है। मुझे खर्राटे सुनाई देते हैं।! वास्तविक जीवन में कोई भी इस तरह की परीक्षा नहीं लिखता है। सॉफ़्टवेयर परीक्षण में ऐसे कोड होते हैं जो अन्य सॉफ़्टवेयर की जांच करते हैं, जो कि, हमेशा सकारात्मक रूप से काम नहीं करेंगे। और (1, 2, 3) == (1, 2, 3) हमेशा काम करेगा। यही कारण है कि हम बाकी किताबों में भी इस तरह के मूर्खतापूर्ण परीक्षणों का उपयोग नहीं करेंगे। हम एक वास्तविक सॉफ्टवेयर परियोजना के लिए परीक्षणों पर विचार करेंगे। हम एक नमूना कार्य परियोजना का उपयोग करेंगे जिसमें परीक्षण कोड की आवश्यकता होती है। उम्मीद है कि यह काफी सरल है आसानी से समझा जा सकता है, लेकिन इतना आसान नहीं है जितना कि उबाऊ हो।

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

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

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

यहाँ कार्य है:

 from collections import namedtuple Task = namedtuple('Task', ['summary', 'owner', 'done', 'id']) 

इससे पहले कि हम उदाहरणों में कूदते हैं, चलो एक कदम पीछे लेते हैं और इस बारे में बात करते हैं कि कैसे प्राप्त करें और इसे स्थापित करें।

फैक्ट्री नाम्टुपल () फ़ंक्शन पायथन 2.6 के बाद से मौजूद है, लेकिन मुझे अभी भी लगता है कि कई पायथन डेवलपर्स नहीं जानते कि यह कितना अच्छा है। कम से कम, परीक्षण मामलों के लिए कार्य का उपयोग करना (1, 2, 3) == (1, 2, 3) या (1, 2)==3 से अधिक दिलचस्प होगा।

उदाहरणों पर जाने से पहले, आइए एक कदम पीछे हटें और इस बारे में बात करें कि कहाँ से पाइस्टेस्ट करें और इसे कैसे स्थापित करें।

खनन pytest

पाइस्टेस्ट मुख्यालय https://docs.pytest.org । यह आधिकारिक दस्तावेज है। लेकिन यह https://pypi.python.org/pypi/pytest पर PyPI (पायथन पैकेज इंडेक्स) से फैलता है।

PyPI के माध्यम से वितरित अन्य पायथन पैकेजों की तरह, परीक्षण के लिए उपयोग किए जाने वाले आभासी वातावरण में पाइस्टेस्ट स्थापित करने के लिए पाइप का उपयोग करें:

 $ pip3 install -U virtualenv $ python3 -m virtualenv venv $ source venv/bin/activate $ pip install pytest 

यदि आप virtualenv या पाइप से परिचित नहीं हैं, तो मैं आपको पेश करूंगा। पृष्ठ १५ ९ पर परिशिष्ट १, "आभासी वातावरण", पृष्ठ १५ ९ और परिशिष्ट २ देखें।

खिड़कियों, अजगर 2 और वेनव के बारे में क्या?

वर्चुअनव और पाइप उदाहरण को कई POSIX प्रणालियों पर काम करना चाहिए, जैसे कि लिनक्स और मैकओएस, साथ ही पायथन के कई संस्करणों पर, जिसमें पायथन 2.7.9 और बाद के संस्करण शामिल हैं।

लाइन में venv / bin / activate सोर्स विंडोज के लिए काम नहीं करेगा, इसके बजाय venv \ Scripts \ activate.bat का उपयोग करें।
यह करें:

 C:\> pip3 install -U virtualenv C:\> python3 -m virtualenv venv C:\> venv\Scripts\activate.bat (venv) C:\> pip install pytest 

पायथन 3.6 और इसके बाद के संस्करण के लिए, आप virtualenv के बजाय venv के साथ प्राप्त कर सकते हैं, और आपको इसे पहले स्थापित करने के बारे में चिंता करने की आवश्यकता नहीं है। इसे पाइथन 3.6 और बाद में शामिल किया गया है। हालांकि, मैंने सुना है कि कुछ प्लेटफॉर्म अभी भी वर्चुअन के साथ बेहतर व्यवहार करते हैं।

पाइस्टेस्ट चलाएं

 $ pytest --help usage: pytest [options] [file_or_dir] [file_or_dir] [...] ... 

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

उदाहरण के लिए, चलो एक उपनिर्देशिका नामक कार्य बनाते हैं और इस परीक्षण फ़ाइल से शुरू करते हैं:

ch1 / कार्य / test_three.py

 """   Task.""" from collections import namedtuple Task = namedtuple('Task', ['summary', 'owner', 'done', 'id']) Task.__new__.__defaults__ = (None, None, False, None) def test_defaults(): """  ,      .""" t1 = Task() t2 = Task(None, None, False, None) assert t1 == t2 def test_member_access(): """  .field () namedtuple.""" t = Task('buy milk', 'brian') assert t.summary == 'buy milk' assert t.owner == 'brian' assert (t.done, t.id) == (False, None) 

Test_member_access () परीक्षण यह प्रदर्शित करने के लिए है कि इंडेक्स द्वारा नाम nd द्वारा सदस्यों तक कैसे पहुंचा जाए, जो नेमटूप्स का उपयोग करने के मुख्य कारणों में से एक है।

आइए _ddict () और _replace () कार्यक्षमता प्रदर्शित करने के लिए एक और फ़ाइल में कुछ और परीक्षण करें

सभी फ़ील्ड निर्दिष्ट किए बिना टास्क ऑब्जेक्ट बनाने के लिए आप __new __.__ defaults__ उपयोग कर सकते हैं। Test_defaults () परीक्षण का उद्देश्य यह प्रदर्शित करना और परीक्षण करना है कि चूक कैसे काम करती है।

test_member_access() परीक्षण को प्रदर्शित करना चाहिए कि nd नाम के सदस्यों तक कैसे पहुंचें, जो कि इंडेक्स द्वारा उपयोग किए जाने के मुख्य कारणों में से एक नहीं है।
आइए _asdict() और _replace() फ़ंक्शन को प्रदर्शित करने के लिए दूसरी फ़ाइल में कुछ और परीक्षण जोड़ें

ch1 / कार्य / test_four.py

 """   Task.""" from collections import namedtuple Task = namedtuple('Task', ['summary', 'owner', 'done', 'id']) Task.__new__.__defaults__ = (None, None, False, None) def test_asdict(): """_asdict()   .""" t_task = Task('do something', 'okken', True, 21) t_dict = t_task._asdict() expected = {'summary': 'do something', 'owner': 'okken', 'done': True, 'id': 21} assert t_dict == expected def test_replace(): """    fields.""" t_before = Task('finish book', 'brian', False) t_after = t_before._replace(id=10, done=True) t_expected = Task('finish book', 'brian', True, 10) assert t_after == t_expected 

Pytest चलाने के लिए आपके पास फ़ाइलों और निर्देशिकाओं को निर्दिष्ट करने का विकल्प है। यदि आप कोई फ़ाइल या निर्देशिका निर्दिष्ट नहीं करते हैं, तो पाइस्टेस्ट वर्तमान कार्य निर्देशिका और उपनिर्देशिकाओं में परीक्षणों की खोज करेगा। यह test_ के साथ शुरू होने वाली फ़ाइलों को खोजता है या _test के साथ समाप्त होता है। यदि आप ch1 डायरेक्टरी से pytest चलाते हैं, तो कमांड्स के बिना, आप चार फाइलों के लिए परीक्षण चलाएंगे:

 $ cd /path/to/code/ch1 $ pytest ===================== test session starts ====================== collected 6 items test_one.py . test_two.py F tasks/test_four.py .. tasks/test_three.py .. =========================== FAILURES =========================== _________________________ test_failing _________________________ def test_failing(): > assert (1, 2, 3) == (3, 2, 1) E assert (1, 2, 3) == (3, 2, 1) E At index 0 diff: 1 != 3 E Use -v to get the full diff test_two.py:2: AssertionError ============== 1 failed, 5 passed in 0.08 seconds ============== 

केवल हमारे नए कार्य परीक्षणों को चलाने के लिए, आप उन सभी फ़ाइल नामों के साथ pytest प्रदान कर सकते हैं जिन्हें आप चलाना चाहते हैं, या एक निर्देशिका, या उस निर्देशिका से pytest को कॉल करें जहाँ हमारे परीक्षण स्थित हैं:

 $ pytest tasks/test_three.py tasks/test_four.py ===================== test session starts ====================== collected 4 items tasks/test_three.py .. tasks/test_four.py .. =================== 4 passed in 0.02 seconds =================== $ pytest tasks ===================== test session starts ====================== collected 4 items tasks/test_four.py .. tasks/test_three.py .. =================== 4 passed in 0.03 seconds =================== $ cd /path/to/code/ch1/tasks $ pytest ===================== test session starts ====================== collected 4 items test_four.py .. test_three.py .. =================== 4 passed in 0.02 seconds =================== 

पाइस्टेस्ट एक्ज़ीक्यूशन पार्ट, जहाँ पाइस्टेस्ट पास होता है और पाता है कि कौन सा टेस्ट चलाना है, टेस्ट डिस्कवरी कहलाता है। पाइस्टेस्ट उन सभी परीक्षणों को खोजने में सक्षम था जिन्हें हम चलाना चाहते थे क्योंकि हमने उनका नाम पाइस्टेस्ट नामकरण सम्मेलनों के अनुसार रखा था।

निम्नलिखित नामकरण सम्मेलनों का एक संक्षिप्त अवलोकन है ताकि आपके परीक्षण कोड को पाइस्टेस्ट का उपयोग करके पता लगाया जा सके:

• टेस्ट फ़ाइलों को test_<something>.py या <something>_test.py नाम दिया जाना चाहिए।
• परीक्षण विधियों और कार्यों को test_<something> कहा जाना चाहिए।
• टेस्ट कक्षाओं को Test<Something> कहा जाना चाहिए।

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

आइए केवल एक फ़ाइल चलाने के परिणाम पर करीब से नज़र डालें:

 $ cd /path/to/code/ch1/tasks $ pytest test_three.py ================= test session starts ================== platform darwin -- Python 3.6.2, pytest-3.2.1, py-1.4.34, pluggy-0.4.0 rootdir: /path/to/code/ch1/tasks, inifile: collected 2 items test_three.py .. =============== 2 passed in 0.01 seconds =============== 

परिणाम हमें काफी कुछ बताता है।

===== परीक्षण सत्र शुरू होता है ====

।

पाइटेस्ट टेस्ट सेशन शुरू करने के लिए एक एलिगेंट सेपरेटर प्रदान करता है। एक सत्र एक एकल pytest कॉल है, जिसमें कई निर्देशिकाओं में चल रहे सभी परीक्षण शामिल हैं। यह सत्र परिभाषा महत्वपूर्ण हो जाती है, जब मैं पृष्ठ 56 पर, स्थिरता क्षेत्र परिभाषा में पाइस्टेस्ट जुड़नार के संबंध में सत्र क्षेत्र के बारे में बात करता हूं।

डार्विन मंच - मेरे मैक पर। विंडोज कंप्यूटर पर, प्लेटफॉर्म अलग है। पायथन और पाइस्टेस्ट के संस्करण निम्नलिखित हैं, साथ ही पाइस्टेस्ट पैकेज पर निर्भरता भी। Pyest के कार्यान्वयन में मदद करने के लिए pyest टीम द्वारा py और pluggy दोनों को विकसित किया गया पैकेज है।

rootdir: / path / to / code / ch1 / कार्यों, inifile:

rootdir सभी निर्देशिकाओं के लिए शीर्ष-सबसे साझा निर्देशिका है जिसमें परीक्षण कोड खोजा जाता है। inifile (यहां खाली) उपयोग की गई कॉन्फ़िगरेशन फ़ाइलों को सूचीबद्ध करता है। कॉन्फ़िगरेशन फ़ाइलें pytest.ini , tox.ini या setup.cfg । कॉन्फ़िगरेशन फ़ाइलों के बारे में अधिक जानकारी के लिए, पृष्ठ 6 पर अध्याय 6, "कॉन्फ़िगरेशन" देखें।

2 आइटम एकत्र किए

ये एक फ़ाइल में दो परीक्षण कार्य हैं।

test_three.py ..

test_three.py परीक्षण फ़ाइल दिखाता है। प्रत्येक परीक्षण फ़ाइल के लिए एक पंक्ति है। दो बिंदुओं का मतलब है कि परीक्षण पास किए गए हैं - प्रत्येक परीक्षण फ़ंक्शन या विधि के लिए एक बिंदु। अंक केवल उत्तीर्ण परीक्षणों के लिए अभिप्रेत हैं। क्रमशः F, E, s, x, और X के साथ विफलताएं, त्रुटियां, स्किप, xfails और xpasses को दर्शाया जाता है। यदि आप पासिंग टेस्ट के लिए अधिक अंक देखना चाहते हैं, तो -v या --verbose विकल्प का उपयोग करें।

== 2 0.01 सेकंड में पारित ==

यह रेखा पारित परीक्षणों की संख्या और पूरे परीक्षण सत्र पर बिताए गए समय को संदर्भित करती है। यदि पास परीक्षण हैं, तो यहां प्रत्येक श्रेणी की संख्या भी दर्शाई जाएगी।

एक परीक्षा परिणाम एक प्राथमिक तरीका है जिसमें एक उपयोगकर्ता एक परीक्षण कर रहा है या परिणाम देखने के बाद समझ सकता है कि परीक्षण के दौरान क्या हुआ। पाइस्टेस्ट में, परीक्षण कार्यों के कई अलग-अलग परिणाम हो सकते हैं, न कि केवल पास या असफल। यहाँ परीक्षण समारोह के संभावित परिणाम हैं:

• PASSED (।): टेस्ट सफलतापूर्वक पूरा हुआ।
• FAILED (F): टेस्ट फेल (या XPASS + सख्त)।
• SKIPPED (s): परीक्षण छोड़ दिया गया था। आप पृष्ठ 34 पर, लंघन परीक्षण अनुभाग में चर्चा किए गए @pytest.mark.skip() या pytest.mark.skipif() सज्जाकारों का उपयोग करके परीक्षण को छोड़ने के लिए बाध्य कर सकते हैं।
• xfail (x): परीक्षा उत्तीर्ण नहीं होनी चाहिए, इसे लॉन्च किया गया था और असफल रहा था। आप पृष्ठ 37 पर परीक्षण चिह्नों में वर्णित @pytest.mark.xfail() डेकोरेटर का उपयोग करके विफल होने के लिए परीक्षण का निर्देश देने के लिए pytest को बाध्य कर सकते हैं।
• XPASS (X): परीक्षण पास नहीं होना चाहिए था, इसे लॉन्च किया गया और पारित किया गया! ...
• त्रुटि (ई): परीक्षण फ़ंक्शन के बाहर एक अपवाद उत्पन्न हुआ, या तो स्थिरता में, अध्याय 3 में चर्चा की गई, पृष्ठ 49 पर, पाइस्टेस्ट फिक्स्चर, या हुक फ़ंक्शन में, अध्याय 5 में चर्चा की गई, प्लगइन्स, पृष्ठ 95 पर।

केवल एक टेस्ट में प्रदर्शन

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

 $ cd /path/to/code/ch1 $ pytest -v tasks/test_four.py::test_asdict =================== test session starts =================== collected 3 items tasks/test_four.py::test_asdict PASSED ================ 1 passed in 0.01 seconds ================= 

अब कुछ विकल्पों पर नजर डालते हैं।

विकल्प का उपयोग करना

हमने एक-दो बार वर्बोज़, -v या --verbose विकल्प का उपयोग किया है, लेकिन कई और विकल्प हैं जो जानने लायक हैं। हम इस पुस्तक में उन सभी का उपयोग नहीं करने जा रहे हैं, केवल कुछ। आप pytest --help विकल्प का उपयोग करके पूरी सूची देख सकते हैं।

नीचे कुछ विकल्प दिए गए हैं जो पाइस्टेस्ट के साथ काम करते समय बहुत उपयोगी होते हैं। यह पूरी सूची नहीं है, लेकिन ये विकल्प शुरू करने के लिए पर्याप्त हैं।

 $ pytest --help usage: pytest [options] [file_or_dir] [file_or_dir] [...] ... subset of the list ... positional arguments: file_or_dir general: -k EXPRESSION only run tests which match the given substring expression. An expression is a python evaluatable expression where all names are substring-matched against test names and their parent classes. Example: -k 'test_method or test_other' matches all test functions and classes whose name contains 'test_method' or 'test_other', while -k 'not test_method' matches those that don't contain 'test_method' in their names. Additionally keywords are matched to classes and functions containing extra names in their 'extra_keyword_matches' set, as well as functions which have names assigned directly to them. -m MARKEXPR only run tests matching given mark expression. example: -m 'mark1 and not mark2'. --markers show markers (builtin, plugin and per-project ones). -x, --exitfirst exit instantly on first error or failed test. --maxfail=num exit after first num failures or errors. ... --capture=method per-test capturing method: one of fd|sys|no. -s shortcut for --capture=no. ... --lf, --last-failed rerun only the tests that failed at the last run (or all if none failed) --ff, --failed-first run all tests but run the last failures first. This may re-order tests and thus lead to repeated fixture setup/teardown ... reporting: -v, --verbose increase verbosity. -q, --quiet decrease verbosity. --verbosity=VERBOSE set verbosity ... -l, --showlocals show locals in tracebacks (disabled by default). --tb=style traceback print mode (auto/long/short/line/native/no). ... --durations=N show N slowest setup/test durations (N=0 for all). ... collection: --collect-only only collect tests, don't execute them. ... test session debugging and configuration: --basetemp=dir base temporary directory for this test run.(warning: this directory is removed if it exists) --version display pytest lib version and import information. -h, --help show help message and configuration info 

केवल---collect

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

 $ cd /path/to/code/ch1 $ pytest --collect-only =================== test session starts =================== collected 6 items <Module 'test_one.py'> <Function 'test_passing'> <Module 'test_two.py'> <Function 'test_failing'> <Module 'tasks/test_four.py'> <Function 'test_asdict'> <Function 'test_replace'> <Module 'tasks/test_three.py'> <Function 'test_defaults'> <Function 'test_member_access'> ============== no tests ran in 0.03 seconds =============== 

--collect-only यह सत्यापित करने के लिए उपयोगी है कि परीक्षण चलाने से पहले परीक्षण का चयन करने वाले अन्य विकल्प सही ढंग से चुने गए हैं। हम इसे -k साथ फिर से उपयोग करेंगे यह दिखाने के लिए कि यह कैसे काम करता है।

-प्रश्न

-k आपको परीक्षण कार्यों को परिभाषित करने के लिए एक अभिव्यक्ति का उपयोग करने की अनुमति देता है।

एक बहुत शक्तिशाली विकल्प! इसका उपयोग एक अलग परीक्षण चलाने के लिए एक शॉर्टकट के रूप में किया जा सकता है, अगर नाम अद्वितीय है, या उन परीक्षणों का एक सेट चलाएं जिनके नामों में एक सामान्य उपसर्ग या प्रत्यय है। मान लीजिए कि आप परीक्षण test_asdict() और test_defaults() चलाना चाहते हैं। आप फ़िल्टर की जाँच कर सकते हैं: --collect-only -

 $ cd /path/to/code/ch1 $ pytest -k "asdict or defaults" --collect-only =================== test session starts =================== collected 6 items <Module 'tasks/test_four.py'> <Function 'test_asdict'> <Module 'tasks/test_three.py'> <Function 'test_defaults'> =================== 4 tests deselected ==================== ============== 4 deselected in 0.03 seconds =============== 

अहा! यह हमारी जरूरत के समान है। अब आप उन्हें हटा सकते हैं

 $ pytest -k "asdict or defaults" =================== test session starts =================== collected 6 items tasks/test_four.py . tasks/test_three.py . =================== 4 tests deselected ==================== ========= 2 passed, 4 deselected in 0.03 seconds ========== 

ऊप्स! बस इशारा करता है। तो फिर वे पास हो गए। लेकिन क्या वे सही परीक्षण थे? पता लगाने का एक तरीका है -v या --verbose का उपयोग करना:

 $ pytest -v -k "asdict or defaults" =================== test session starts =================== collected 6 items tasks/test_four.py::test_asdict PASSED tasks/test_three.py::test_defaults PASSED =================== 4 tests deselected ==================== ========= 2 passed, 4 deselected in 0.02 seconds ========== 

अहा! ये सही परीक्षण थे।

-M MAREXEXPR

मार्कर एक साथ चलने के लिए परीक्षण सुविधाओं के सबसेट को टैग करने के सर्वोत्तम तरीकों में से एक हैं। उदाहरण के रूप में, test_replace() और test_member_access() चलाने का एक तरीका, भले ही वे अलग-अलग फ़ाइलों में हों, उन्हें चिह्नित करना है। किसी भी मार्कर नाम का उपयोग किया जा सकता है। कहते हैं कि आप run_these_please का उपयोग करना चाहते हैं। इस तरह @pytest.mark.run_these_please डेकोरेटर का उपयोग करके परीक्षणों पर ध्यान दें:

 import pytest ... @pytest.mark.run_these_please def test_member_access(): ... 

अब test_replace() लिए भी test_replace() । तब आप pytest -m run_these_please साथ एक ही मार्कर के साथ सभी परीक्षण चला सकते हैं:

 $ cd /path/to/code/ch1/tasks $ pytest -v -m run_these_please ================== test session starts =================== collected 4 items test_four.py::test_replace PASSED test_three.py::test_member_access PASSED =================== 2 tests deselected =================== ========= 2 passed, 2 deselected in 0.02 seconds ========= 

मार्कर की अभिव्यक्ति के लिए एक मार्कर होना आवश्यक नहीं है। आप दोनों मार्करों के साथ परीक्षण के लिए -m "mark1 and mark2" जैसे विकल्पों का उपयोग कर सकते हैं, -m "mark1 and not mark2" उन परीक्षणों के लिए जिनमें लेबल 1 है, लेकिन लेबल 2 नहीं, -m "mark1 or mark2" परीक्षणों के लिए एक आदि के साथ, मैं मार्किंग वेरिफिकेशन मेथड्स में मार्करों के बारे में अधिक विस्तार से चर्चा करूंगा, पृष्ठ 31 पर।

-x, --exitfirst

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

 $ cd /path/to/code/ch1 $ pytest -x ====================== test session starts ==================== collected 6 items test_one.py . test_two.py F ============================ FAILURES ========================= __________________________ test_failing _______________________ def test_failing(): > assert (1, 2, 3) == (3, 2, 1) E assert (1, 2, 3) == (3, 2, 1) E At index 0 diff: 1 != 3 E Use -v to get the full diff test_two.py:2: AssertionError =============== 1 failed, 1 passed in 0.38 seconds ============ 

आउटपुट के शीर्ष पर, आप देखते हैं कि सभी छह परीक्षण (या "आइटम") एकत्र किए गए थे, और नीचे की रेखा पर आप देखते हैं कि एक परीक्षण विफल हो गया और एक पास हो गया, और पाइस्टेस्ट ने "बाधित" लाइन प्रदर्शित की। हमें यह बताने के लिए कि वह बंद है। -x बिना -x सभी छह परीक्षण चलेंगे। चलो फिर से -x बिना दोहराएं। हम स्टैक ट्रेसिंग को अक्षम करने के लिए भी --tb=no का उपयोग करते हैं, क्योंकि आपने पहले ही इसे देख लिया है और आपको इसे फिर से देखने की आवश्यकता नहीं है:

 $ cd /path/to/code/ch1 $ pytest --tb=no =================== test session starts =================== collected 6 items test_one.py . test_two.py F tasks/test_four.py .. tasks/test_three.py .. =========== 1 failed, 5 passed in 0.09 seconds ============ 

, -x , pytest test_two.py .

--maxfail=num

-x . , , , --maxfail , , . , . , --maxfail = 2 , , --maxfail = 1 , -x :

 $ cd /path/to/code/ch1 $ pytest --maxfail=2 --tb=no =================== test session starts =================== collected 6 items test_one.py . test_two.py F tasks/test_four.py .. tasks/test_three.py .. =========== 1 failed, 5 passed in 0.08 seconds ============ $ pytest --maxfail=1 --tb=no =================== test session starts =================== collected 6 items test_one.py . test_two.py F !!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!! =========== 1 failed, 1 passed in 0.19 seconds ============ 

E --tb=no , .

-s and --capture=method

-s — , stdout , . --capture=no . , . , , , . -s --capture=no . print() , .

, , -l/--showlocals , , .

--capture=fd --capture=sys . — --capture=sys sys.stdout/stderr mem-. --capture=fd 1 2 .

sys fd . , , . -s . , -s , .

; . , , .

-lf, --last-failed

. --lf :

, --tb , , .

 $ cd /path/to/code/ch1 $ pytest --lf =================== test session starts =================== run-last-failure: rerun last 1 failures collected 6 items test_two.py F ======================== FAILURES ========================= ______________________ test_failing _______________________ def test_failing(): > assert (1, 2, 3) == (3, 2, 1) E assert (1, 2, 3) == (3, 2, 1) E At index 0 diff: 1 != 3 E Use -v to get the full diff test_two.py:2: AssertionError =================== 5 tests deselected ==================== ========= 1 failed, 5 deselected in 0.08 seconds ========== 

–ff, --failed-first

--ff/--failed-first , --last-failed , , :

 $ cd /path/to/code/ch1 $ pytest --ff --tb=no =================== test session starts =================== run-last-failure: rerun last 1 failures first collected 6 items test_two.py F test_one.py . tasks/test_four.py .. tasks/test_three.py .. =========== 1 failed, 5 passed in 0.09 seconds ============ 

test_failing() test\_two.py test\_one.py . , test_failing() , --ff

-v, --verbose

-v/--verbose . , , .

, --ff --tb=no :

 $ cd /path/to/code/ch1 $ pytest -v --ff --tb=no =================== test session starts =================== run-last-failure: rerun last 1 failures first collected 6 items test_two.py::test_failing FAILED test_one.py::test_passing PASSED tasks/test_four.py::test_asdict PASSED tasks/test_four.py::test_replace PASSED tasks/test_three.py::test_defaults PASSED tasks/test_three.py::test_member_access PASSED =========== 1 failed, 5 passed in 0.07 seconds ============ 

FAILED PASSED.

-q, --quiet

-q/--quiet -v/--verbose ; . --tb=line , .

- q :

 $ cd /path/to/code/ch1 $ pytest -q .F.... ======================== FAILURES ========================= ______________________ test_failing _______________________ def test_failing(): > assert (1, 2, 3) == (3, 2, 1) E assert (1, 2, 3) == (3, 2, 1) E At index 0 diff: 1 != 3 E Full diff: E - (1, 2, 3) E ? ^ ^ E + (3, 2, 1) E ? ^ ^ test_two.py:2: AssertionError 1 failed, 5 passed in 0.08 seconds 

-q , . -q ( --tb=no ), , .

-l, --showlocals

-l/--showlocals tracebacks .

. test_replace()

 t_expected = Task('finish book', 'brian', True, 10) 

पर

 t_expected = Task('finish book', 'brian', True, 11) 

10 11 . . --l/--showlocals :

 $ cd /path/to/code/ch1 $ pytest -l tasks =================== test session starts =================== collected 4 items tasks/test_four.py .F tasks/test_three.py .. ======================== FAILURES ========================= ______________________ test_replace _______________________ @pytest.mark.run_these_please def test_replace(): """replace() should change passed in fields.""" t_before = Task('finish book', 'brian', False) t_after = t_before._replace(id=10, done=True) t_expected = Task('finish book', 'brian', True, 11) > assert t_after == t_expected E AssertionError: assert Task(summary=...e=True, id=10) == Task(summary='...e=True, id=11) E At index 3 diff: 10 != 11 E Use -v to get the full diff t_after = Task(summary='finish book', owner='brian', done=True, id=10) t_before = Task(summary='finish book', owner='brian', done=False, id=None) t_expected = Task(summary='finish book', owner='brian', done=True, id=11) tasks\test_four.py:28: AssertionError =========== 1 failed, 3 passed in 0.08 seconds ============ 

t_after , t_before t_expected , assert-.

--tb=style

--tb=style . pytest , , . tracebacks , , . --tb=style . , , short, line no. short assert E ; line ; no .

test_replace() , , . --tb=no

 $ cd /path/to/code/ch1 $ pytest --tb=no tasks =================== test session starts =================== collected 4 items tasks/test_four.py .F tasks/test_three.py .. =========== 1 failed, 3 passed in 0.04 seconds ============ 

--tb=line in many cases is enough to tell what's wrong. If you have a ton of failing tests, this option can help to show a pattern in the failures:

--tb=line , , . , :

 $ pytest --tb=line tasks =================== test session starts =================== collected 4 items tasks/test_four.py .F tasks/test_three.py .. ======================== FAILURES ========================= /path/to/code/ch1/tasks/test_four.py:20: AssertionError: assert Task(summary=...e=True, id=10) == Task( summary='...e=True, id=11) =========== 1 failed, 3 passed in 0.05 seconds ============ 

verbose tracebacks --tb=short :

 $ pytest --tb=short tasks =================== test session starts =================== collected 4 items tasks/test_four.py .F tasks/test_three.py .. ======================== FAILURES ========================= ______________________ test_replace _______________________ tasks/test_four.py:20: in test_replace assert t_after == t_expected E AssertionError: assert Task(summary=...e=True, id=10) == Task( summary='...e=True, id=11) E At index 3 diff: 10 != 11 E Use -v to get the full diff =========== 1 failed, 3 passed in 0.04 seconds ============ 

, , .

, .

pytest --tb=long traceback. pytest --tb=auto tracebacks , . . pytest --tb=native traceback .

--durations=N

--durations=N , . ; N tests/setups/teardowns . --durations=0 , .

, time.sleep(0.1) . , :

 $ cd /path/to/code/ch1 $ pytest --durations=3 tasks ================= test session starts ================= collected 4 items tasks/test_four.py .. tasks/test_three.py .. ============== slowest 3 test durations =============== 0.10s call tasks/test_four.py::test_replace 0.00s setup tasks/test_three.py::test_defaults 0.00s teardown tasks/test_three.py::test_member_access ============== 4 passed in 0.13 seconds 

sleep , . : call(), (setup) (teardown). , , , , . 3, pytest Fixtures, . 49.

--version

--version pytest , :

 $ pytest --version This is pytest version 3.0.7, imported from /path/to/venv/lib/python3.5/site-packages/pytest.py 

pytest , pytest site-packages .

-h, --help

-h/--help , , pytest. , stock- pytest, , , .

-h :

• : pytest [] [file_or_dir] [file_or_dir] [...]
• ,
• , ini , 6, , . 113
• , pytest ( 6, , . 113)
• , pytest --markers , 2, , . 23
• , pytest --fixtures , 3, pytest, . 49

:

 (shown according to specified file_or_dir or current dir if not specified) 

, , . , pytest conftest.py, - (hook functions), , .

pytest conftest.py . conftest.py ini, pytest.ini 6 «», 113.

अभ्यास

1. , python -m virtualenv python -m venv . , , , , , . , . 1, , . 155, .

   
   

2. .

   
   

    - $ source venv/bin/activate - $ deactivate On Windows: - C:\Users\okken\sandbox>venv\scripts\activate.bat - C:\Users\okken\sandbox>deactivate 

   
   

3. pytest . . 2, pip, 159, . , pytest, , .

   
   

4. . , . pytest .

   
   

5. assert. assert something == something_else; , :

   
   
   • assert 1 in [2, 3, 4]
   • assert a < b
   • assert 'fizz' not in 'fizzbuzz'
   
   

आगे क्या है

, pytest . , . , , , , .

पीछे अगला