पायथन के साथ पायथन परीक्षण। कॉन्फ़िगरेशन, अध्याय 6

पीछे अगला

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

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

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

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

विन्यास

इस पुस्तक में अब तक मैंने विभिन्न गैर-परीक्षण फ़ाइलों के बारे में बात की है, जो मुख्य रूप से पासिंग को प्रभावित करती हैं, जो कि conftest.py के अपवाद के साथ है, जिसे मैंने अध्याय 5, प्लगइन्स, पृष्ठ 95 पर कुछ विवरण में कवर किया है। इस अध्याय में, हम कॉन्फ़िगरेशन फ़ाइलों को देखेंगे। कि pytest को प्रभावित करते हैं, चर्चा करते हैं कि कैसे pytest अपने व्यवहार को उनके आधार पर बदलता है, और कार्य प्रोजेक्ट कॉन्फ़िगरेशन फ़ाइलों में कुछ परिवर्तन करता है।

पाइस्टेस्ट कॉन्फ़िगरेशन फ़ाइलों को समझना

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

आपको निम्नलिखित जानना चाहिए:

• pytest.ini : यह मुख्य Pytest कॉन्फ़िगरेशन फ़ाइल है जो आपको डिफ़ॉल्ट व्यवहार को बदलने की अनुमति देती है। चूँकि आप काफी कुछ विन्यास परिवर्तन कर सकते हैं, इस अध्याय का अधिकांश भाग उन सेटिंग्स के लिए समर्पित है जिन्हें आप pytest.ini में बना सकते हैं।
• conftest.py : यह एक स्थानीय प्लगइन है जो हुक फ़ंक्शन और जुड़नार को उस निर्देशिका से कनेक्ट करने की अनुमति देता है जिसमें conftest.py फ़ाइल conftest.py और इसके सभी उपनिर्देशिकाएं। पृष्ठ 95 पर अध्याय 5 "प्लगइन्स" में conftest.py फ़ाइल वर्णित है।
• __init__.py : जब प्रत्येक परीक्षण उपनिर्देशिका में रखा जाता है, तो यह फ़ाइल आपको कई परीक्षण निर्देशिकाओं में समान परीक्षण फ़ाइल नाम रखने की अनुमति देती है। हम पृष्ठ १२० पर "टालना फ़ाइल नाम टकराव से बचने" लेख में परीक्षण निर्देशिका में __init__.py फ़ाइलों के बिना क्या गलत होगा के एक उदाहरण को देखेंगे।

यदि आप विषाक्त का उपयोग करते हैं, तो आप इसमें रुचि लेंगे:

• tox.ini : यह फ़ाइल pytest.ini समान है, लेकिन pytest.ini लिए। हालाँकि, आप अपने pytest कॉन्फ़िगरेशन को tox.ini फ़ाइल और pytest.ini फ़ाइल, दोनों में रखने के बजाय pytest रख सकते हैं, जिससे आप एक कॉन्फ़िगरेशन फ़ाइल सहेज सकते हैं। पृष्ठ १२५ पर अध्याय,, अन्य उपकरणों के साथ पाइस्टेस्ट का उपयोग करते हुए टॉक्स की चर्चा की गई है।

यदि आप एक अजगर पैकेज (जैसे कार्य) वितरित करना चाहते हैं, तो यह फ़ाइल ब्याज की होगी:

• setup.cfg : यह भी एक INI फ़ाइल है जो setup.py के व्यवहार को प्रभावित करती है। आप python setup.py test चलाने के python setup.py test और अपने सभी पाइस्टेस्ट परीक्षण चलाने के लिए setup.py लिए कुछ पंक्तियाँ जोड़ सकते हैं। यदि आप पैकेज वितरित कर रहे हैं, तो आपके पास पहले से ही setup.cfg फ़ाइल हो सकती है और आप इस फ़ाइल का उपयोग Pytest कॉन्फ़िगरेशन को संग्रहीत करने के लिए कर सकते हैं। आप यह देखेंगे कि पृष्ठ 175 पर परिशिष्ट 4, "पैकेजिंग और वितरण पायथन प्रोजेक्ट्स" में यह कैसे किया जाता है।

इससे कोई फर्क नहीं पड़ता कि आपने किस फाइल में सबसे ज्यादा कॉन्फिगरेशन डाला है, फॉर्मेट मूल रूप से एक ही होगा।

pytest.ini :

ch6 / format / pytest.ini

 [pytest] addopts = -rsxX -l --tb=short --strict xfail_strict = true ... more options ... 

tox.ini :

ch6 / format / tox.ini

 ... tox specific stuff ... [pytest] addopts = -rsxX -l --tb=short --strict xfail_strict = true ... more options ... 

setup.cfg :

ch6 / format / setup.cfg

 ... packaging specific stuff ... [tool:pytest] addopts = -rsxX -l --tb=short --strict xfail_strict = true ... more options ... 

एकमात्र अंतर यह है कि setup.cfg के लिए अनुभाग शीर्षलेख [tool:pytest] बजाय [pytest] ।

Pytest –help के साथ मान्य इन-फाइल विकल्प सूचीबद्ध करें

आप pytest.ini से pytest --help लिए सभी मान्य मापदंडों की सूची प्राप्त कर सकते हैं:

 $ pytest --help ... [pytest] ini-options in the first pytest.ini|tox.ini|setup.cfg file found: markers (linelist) markers for test functions empty_parameter_set_mark (string) default marker for empty parametersets norecursedirs (args) directory patterns to avoid for recursion testpaths (args) directories to search for tests when no files or directories are given in the command line. console_output_style (string) console output: classic or with additional progress information (classic|progress). usefixtures (args) list of default fixtures to be used with this project python_files (args) glob-style file patterns for Python test module discovery python_classes (args) prefixes or glob names for Python test class discovery python_functions (args) prefixes or glob names for Python test function and method discovery xfail_strict (bool) default for the strict parameter of xfail markers when not given explicitly (default: False) junit_suite_name (string) Test suite name for JUnit report junit_logging (string) Write captured log messages to JUnit report: one of no|system-out|system-err doctest_optionflags (args) option flags for doctests doctest_encoding (string) encoding used for doctest files cache_dir (string) cache directory path. filterwarnings (linelist) Each line specifies a pattern for warnings.filterwarnings. Processed after -W and --pythonwarnings. log_print (bool) default value for --no-print-logs log_level (string) default value for --log-level log_format (string) default value for --log-format log_date_format (string) default value for --log-date-format log_cli (bool) enable log display during test run (also known as "live logging"). log_cli_level (string) default value for --log-cli-level log_cli_format (string) default value for --log-cli-format log_cli_date_format (string) default value for --log-cli-date-format log_file (string) default value for --log-file log_file_level (string) default value for --log-file-level log_file_format (string) default value for --log-file-format log_file_date_format (string) default value for --log-file-date-format addopts (args) extra command line options minversion (string) minimally required pytest version xvfb_width (string) Width of the Xvfb display xvfb_height (string) Height of the Xvfb display xvfb_colordepth (string) Color depth of the Xvfb display xvfb_args (args) Additional arguments for Xvfb xvfb_xauth (bool) Generate an Xauthority token for Xvfb. Needs xauth. ... 

आप इस अध्याय में इन सभी सेटिंग्स को doctest_optionflags के अपवाद के साथ doctest_optionflags , जिसकी चर्चा अध्याय 7, पृष्ठ 125 पर "अन्य उपकरणों के साथ pytest का उपयोग करते हुए" में की गई है।

प्लगइन्स ini फ़ाइल विकल्प जोड़ सकते हैं

सेटिंग्स की पिछली सूची एक स्थिर नहीं है। प्लगइन्स (और conftest.py फ़ाइलों के लिए) में ini फ़ाइल विकल्प जोड़ना संभव है। अतिरिक्त विकल्प pytest --help कमांड के आउटपुट में भी जोड़े जाएंगे।
अब कुछ विन्यास परिवर्तनों को देखते हैं जिन्हें हम कोर pytest में उपलब्ध .ini फ़ाइल की अंतर्निहित सेटिंग्स का उपयोग करके कर सकते हैं।

डिफ़ॉल्ट कमांड लाइन विकल्प बदलें

आपने पहले से ही pytest के लिए कुछ कमांड लाइन विकल्पों का उपयोग किया है, जैसे कि -v/--verbose -l/--showlocals आउटपुट के लिए -l/--showlocals विफल परीक्षण के लिए स्टैक ट्रेस के साथ स्थानीय चर देखने के लिए। आप पा सकते हैं कि आप हमेशा इन options—or कुछ का उपयोग करते options—or them—for a project उपयोग करना पसंद करते हैं। यदि आप पैरामीटर की आवश्यकता के लिए addopts में pytest.ini स्थापित addopts , तो आपको अब उन्हें दर्ज नहीं करना होगा। यहाँ एक सेट है जो मुझे पसंद है:

 [pytest] addopts = -rsxX -l --tb=short --strict 

-rsxX पाइस्टेस्ट को सभी skipped , xfailed या xpassed परीक्षणों के कारणों की रिपोर्ट करने की अनुमति देता है। -l स्विच प्रत्येक विफलता के मामले में pytest को स्थानीय चर के लिए एक स्टैक ट्रेस प्रदर्शित करने की अनुमति देता है। --tb=short ढेर के ट्रेस को हटा देगा। हालांकि, यह फ़ाइल और लाइन नंबर को छोड़ देगा। - --strict टोकन के उपयोग को प्रतिबंधित करता है यदि वे विन्यास फाइल में पंजीकृत नहीं हैं। आप देखेंगे कि इसे अगले भाग में कैसे करें।

मार्कर टाइपो से बचने के लिए मार्कर पंजीकरण

कस्टम मार्कर, जैसा कि पृष्ठ 31 पर "लेबलिंग टेस्ट फ़ंक्शंस" में वर्णित है, आपको एक विशिष्ट मार्कर के साथ चलने के लिए परीक्षणों के सबसेट को चिह्नित करने की अनुमति देने के लिए महान हैं। हालाँकि, मार्कर में गलती करना बहुत आसान है और अंततः कुछ परीक्षणों को @pytest.mark.smoke और कुछ को @pytest.mark.somke टैग किया @pytest.mark.somke । डिफ़ॉल्ट रूप से, यह कोई त्रुटि नहीं है। पाइस्टेस्ट को लगता है कि आपने दो मार्कर बनाए हैं। हालाँकि, यह pytest.ini में टोकन रजिस्टर करके तय किया जा सकता है, उदाहरण के लिए:

 [pytest] ... markers = smoke: Run the smoke test test functions get: Run the test functions that test tasks.get() ... 

इन मार्करों को पंजीकृत करके, अब आप उन्हें अपने विवरण के साथ pytest --markers साथ भी देख सकते हैं:

 $ cd /path/to/code/ch6/b/tasks_proj/tests $ pytest --markers @pytest.mark.smoke: Run the smoke test test functions @pytest.mark.get: Run the test functions that test tasks.get() @pytest.mark.skip(reason=None): skip the ... ... 

यदि मार्कर पंजीकृत नहीं हैं, तो वे - --markers सूची में दिखाई नहीं देंगे। जब वे पंजीकृत होते हैं, तो वे सूचीबद्ध होते हैं, और यदि आप उपयोग करते हैं - --strict , त्रुटियों के साथ किसी भी टोकन या अपंजीकृत को त्रुटियों के रूप में प्रदर्शित किया जाता है। ch6/a/tasks_proj और ch6/b/tasks_proj बीच एकमात्र अंतर pytest.ini फ़ाइल की सामग्री है। ch6/a खाली है। आइए बिना किसी मार्कर को पंजीकृत किए परीक्षण चलाने की कोशिश करें:

 $ cd /path/to/code/ch6/a/tasks_proj/tests $ pytest --strict --tb=line ============================= test session starts ============================= collected 45 items / 2 errors =================================== ERRORS ==================================== ______________________ ERROR collecting func/test_add.py ______________________ 'smoke' not a registered marker ________________ ERROR collecting func/test_api_exceptions.py _________________ 'smoke' not a registered marker !!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!! =========================== 2 error in 1.10 seconds =========================== 

यदि आप अपने मार्करों को पंजीकृत करने के लिए pytest.ini में मार्करों का उपयोग करते हैं, तो आप अपने addopts साथ-साथ उस पर addopts दौरान भी जोड़ सकते हैं। आप मुझे बाद में धन्यवाद देंगे। चलो आगे बढ़ते हैं और कार्य परियोजना में एक pytest.ini फ़ाइल जोड़ते हैं:

यदि आप अपने मार्करों को पंजीकृत करने के लिए pytest.ini में मार्करों का उपयोग करते हैं, तो आप अपने addopts भी जोड़ सकते हैं। आप मुझे बाद में धन्यवाद देंगे। चलो जारी रखें और pytest.ini फ़ाइल को कार्य प्रोजेक्ट में जोड़ें:

यदि आप टोकन को पंजीकृत करने के लिए pytest.ini में टोकन का उपयोग करते हैं, तो आप --strict साथ मौजूदा वाले को भी जोड़ सकते हैं। शांत! pytest.ini धन्यवाद pytest.ini और tasks परियोजना में pytest.ini फ़ाइल जोड़ें:

ch6 / b / task_proj / परीक्षण / pytest.ini

 [pytest] addopts = -rsxX -l --tb=short --strict markers = smoke: Run the smoke test test functions get: Run the test functions that test tasks.get() 

यहां डिफ़ॉल्ट रूप से पसंदीदा झंडे का संयोजन है:

• -rsxX यह -rsxX करने के लिए -rsxX कौन से परीक्षण छोड़ दिए गए हैं, xfailed या xpassed,
• --tb = short विफलताओं पर एक छोटे निशान के लिए छोटा,
• --strict केवल घोषित टोकन की अनुमति देने का --strict ।
  और परियोजना के लिए मार्करों की एक सूची।

इससे हमें धुआं परीक्षण सहित परीक्षण करने की अनुमति मिलनी चाहिए:

 $ cd /path/to/code/ch6/b/tasks_proj/tests $ pytest --strict -m smoke ===================== test session starts ====================== collected 57 items func/test_add.py . func/test_api_exceptions.py .. ===================== 54 tests deselected ====================== =========== 3 passed, 54 deselected in 0.06 seconds ============ 

न्यूनतम पाइस्टेस्ट आवश्यकता

न्यूनतम minversion पैरामीटर minversion परीक्षणों के लिए अपेक्षित न्यूनतम पाइस्ट संस्करण को निर्दिष्ट करने की अनुमति देता है। उदाहरण के लिए, मैंने परीक्षणों में "काफी करीब" समानता निर्धारित करने के लिए फ्लोटिंग-पॉइंट नंबरों का परीक्षण करते समय approx() का उपयोग करने का इरादा किया था। लेकिन संस्करण 3.0 तक यह फ़ंक्शन पाइस्टेस्ट में पेश नहीं किया गया था। भ्रम से बचने के लिए, मैं निम्नलिखित परियोजनाओं को जोड़ता हूं जो approx() उपयोग करते हैं:

 [pytest] minversion = 3.0 

इस प्रकार, अगर कोई पाइस्टेस्ट के पुराने संस्करण का उपयोग करके परीक्षण चलाने की कोशिश करता है, तो एक त्रुटि संदेश दिखाई देगा।

गलत स्थानों पर जाने से रोकें

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

norecurse लिए डिफ़ॉल्ट मान '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' अपने आभासी वातावरण का नाम रखने का एक अच्छा कारण है '.venv', क्योंकि डॉट के साथ शुरू होने वाली सभी निर्देशिकाएं दिखाई नहीं देंगी।

कार्य परियोजना के मामले में, src को निर्दिष्ट करने के लिए चोट नहीं पहुंचेगी, क्योंकि pytest का उपयोग करके परीक्षण फ़ाइलों में खोज करना समय की बर्बादी होगी।

 [pytest] norecursedirs = .* venv src *.egg dist build 

उस पैरामीटर को ओवरराइड करते समय जिसका पहले से ही उपयोगी मान है, जैसे कि यह पैरामीटर, यह जानना उपयोगी है कि डिफ़ॉल्ट मान क्या हैं और जिन्हें आप की आवश्यकता है, उन्हें वापस करें, जैसा कि मैंने पिछले कोड में *.egg dist build के साथ किया था।
norecursedirs परीक्षण पथों के लिए एक प्रकार का परिणाम है, इसलिए आइए इस पर एक नज़र डालते हैं।

परीक्षण निर्देशिका ट्री विनिर्देश

जबकि norecursedirs बताते हैं कि कहाँ देखना है, testpaths बताता है कि कहाँ देखना है। testspaths परीक्षण खोजने के लिए रूट निर्देशिका के सापेक्ष निर्देशिकाओं की एक सूची है। इसका उपयोग केवल तभी किया जाता है जब निर्देशिका, फ़ाइल या nodeid को एक तर्क के रूप में निर्दिष्ट नहीं किया जाता है।

मान लीजिए कि एक Tasks प्रोजेक्ट के लिए हमने pytest.ini को परीक्षणों के बजाय tasks_proj निर्देशिका में रखा:

 \code\tasks_proj>tree/f . │ pytest.ini │ ├───src │ └───tasks │ api.py │ ... │ └───tests │ conftest.py │ pytest.ini │ ├───func │ test_add.py │ ... │ ├───unit │ test_task.py │ __init__.py │ ... 

तब परीक्षण को testpaths में रखना समझदारी हो सकता है:

 [pytest] testpaths = tests 

अब, यदि आप tasks_proj निर्देशिका से pytest चलाते हैं, तो pytest केवल tasks_proj/tests में खोज करेगा। यहां समस्या यह है कि परीक्षणों के विकास और डिबगिंग के दौरान, मैं अक्सर परीक्षण निर्देशिका पर पुनरावृति करता हूं, इसलिए मैं आसानी से पूरे पथ को निर्दिष्ट किए बिना उपनिर्देशिका या फ़ाइल का परीक्षण कर सकता हूं। इसलिए, यह विकल्प इंटरैक्टिव परीक्षण में मेरी थोड़ी मदद करता है।

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

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

टेस्ट डिटेक्शन नियम बदलना

pytest विशिष्ट परीक्षण खोज नियमों के आधार पर चलाने के लिए परीक्षण पाता है। मानक परीक्षण का पता लगाने के नियम:

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

ये मानक पहचान नियम हैं; हालाँकि, आप उन्हें बदल सकते हैं।

python_classes

पाइस्टेस्ट और कक्षाओं के लिए परीक्षण खोजने के लिए सामान्य नियम यह है कि किसी कक्षा को संभावित परीक्षण वर्ग के रूप में माना जाए यदि वह Test* शुरू होता है। वर्ग में __init__() विधि भी नहीं हो सकती है। लेकिन क्या होगा अगर हम अपनी परीक्षा कक्षाओं का नाम <something>Test या <something>Suite चाहते हैं? यह वह जगह है जहाँ python_classes आता python_classes :

 [pytest] python_classes = *Test Test* *Suite 

यह हमें इस तरह वर्गों का नाम देने की अनुमति देता है:

 class DeleteSuite(): def test_delete_1(): ... def test_delete_2(): ... .... 

python_files

pytest_classes तरह, python_files डिफ़ॉल्ट टेस्ट डिटेक्शन नियम को संशोधित करता है, जिसमें ऐसी फाइलें ढूंढना शामिल है जो test_* शुरू होती हैं या अंत में *_test होती हैं।
मान लीजिए कि आपके पास एक कस्टम परीक्षण ढांचा है जिसमें आपने अपनी सभी परीक्षण फ़ाइलों का नाम check_<something>.py । उचित लगता है। अपनी सभी फ़ाइलों का नाम बदलने के बजाय, केवल pytest.ini लिए एक पंक्ति जोड़ें:

 [pytest] python_files = test_* *_test check_* 

बहुत सरल है। अब आप धीरे-धीरे नामकरण सम्मेलन को स्थानांतरित कर सकते हैं यदि आप चाहें, या इसे check_* रूप में छोड़ दें।

python_functions

python_functions दो पिछली सेटिंग्स की तरह काम करता है, लेकिन परीक्षण कार्यों और विधि नामों के लिए। डिफ़ॉल्ट मान test_* । और check_* जोड़ने के लिए - check_* यह अनुमान लगाया - ऐसा करें:

 [pytest] python_functions = test_* check_* 

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

XPASS बैन

xfail_strict = true सेट करना xfail_strict = true अर्थ है कि @pytest.mark.xfail के साथ चिह्नित परीक्षण त्रुटि के कारण के रूप में मान्यता प्राप्त नहीं हैं। मुझे लगता है कि यह सेटिंग हमेशा होनी चाहिए। xfail टोकन के बारे में अधिक जानकारी के लिए xfail पृष्ठ 37 पर "असफलता की प्रतीक्षा में अंकन परीक्षण" देखें।

फ़ाइल का नाम संघर्ष रोकें

परियोजना के प्रत्येक परीक्षण उपनिर्देशिका में __init__.py फ़ाइल होने की उपयोगिता ने मुझे लंबे समय तक भ्रमित किया। हालाँकि, उनके होने या न होने के बीच का अंतर सरल है। यदि आपके पास सभी परीक्षण उपनिर्देशिकाओं में __init__.py फाइलें हैं, तो आपके पास एक ही परीक्षण फ़ाइल का नाम कई निर्देशिकाओं में हो सकता है। और अगर नहीं है, तो यह काम नहीं करेगा।

यहाँ एक उदाहरण है। निर्देशिका और b दोनों में फ़ाइल test_foo.py । इससे कोई फर्क नहीं पड़ता कि इन फ़ाइलों में क्या है, लेकिन इस उदाहरण के लिए वे इस तरह दिखते हैं:

ch6 / dups / a / test_foo.py

 def test_a(): pass 

ch6 / dups / b / test_foo.py

 def test_b(): pass 

इस निर्देशिका संरचना के साथ:

 dups ├── a │ └── test_foo.py └── b └── test_foo.py 

इन फ़ाइलों में समान सामग्री नहीं है, लेकिन परीक्षण दूषित हैं। आप उन्हें अलग से चलाने में सक्षम होंगे, लेकिन pytest से pytest को चलाने का कोई तरीका नहीं है:

 $ cd /path/to/code/ch6/dups $ pytest a ============================= test session starts ============================= collected 1 item a\test_foo.py . ========================== 1 passed in 0.05 seconds =========================== $ pytest b ============================= test session starts ============================= collected 1 item b\test_foo.py . ========================== 1 passed in 0.05 seconds =========================== $ pytest ============================= test session starts ============================= collected 1 item / 1 errors =================================== ERRORS ==================================== _______________________ ERROR collecting b/test_foo.py ________________________ import file mismatch: imported module 'test_foo' has this __file__ attribute: /path/to/code/ch6/dups/a/test_foo.py which is not the same as the test file we want to collect: /path/to/code/ch6/dups/b/test_foo.py HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules !!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!! =========================== 1 error in 0.34 seconds =========================== 

कुछ भी स्पष्ट नहीं है!
यह त्रुटि संदेश इंगित नहीं करता है कि क्या गलत हुआ।

इस परीक्षण को ठीक करने के लिए, बस __init__.py फ़ाइल को उपनिर्देशिकाओं में जोड़ें। यहां समान डुप्लिकेट फ़ाइल नामों के साथ dups_fixed निर्देशिका का एक उदाहरण है, लेकिन __init__.py फ़ाइलों के साथ:

 dups_fixed/ ├── a │ ├── __init__.py │ └── test_foo.py └── b ├── __init__.py └── test_foo.py 

अब हम शीर्ष स्तर से फिर से कोशिश करें dups_fixed :

 $ cd /path/to/code/ch6/ch6/dups_fixed/ $ pytest ============================= test session starts ============================= collected 2 items a\test_foo.py . b\test_foo.py . ========================== 2 passed in 0.15 seconds =========================== 

तो बेहतर होगा।

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

अभ्यास

अध्याय 5 में, प्लगइन्स, पृष्ठ 95 पर, आपने एक पाइस्टेस्ट-नाइस नामक एक प्लगइन बनाया जिसमें एक --nice कमांड-लाइन विकल्प शामिल था। चलो एक अच्छा कहा जाता है कि pytest.ini विकल्प को शामिल करने के लिए विस्तार करें।

अध्याय 5 में, पृष्ठ 95 पर "प्लगइन्स", आपने एक pytest-nice नामक एक प्लगइन बनाया जिसमें --nice कमांड-लाइन --nice । चलो nice कहा जाता है pytest.ini विकल्प को शामिल करने के लिए इसका विस्तार करें।

1. निम्न पंक्ति को pytest_addoption pytest_nice.py हुक फ़ंक्शन में जोड़ें: parser.addini('nice', type='bool', help='Turn failures into opportunities.')
2. प्लगइन में स्थान जो getoption() उपयोग करते हैं, getoption() getini('nice') भी कॉल करना होगा। ये बदलाव करें।
3. pytest.ini फ़ाइल में nice जोड़कर इसे मैन्युअल रूप से सत्यापित करें।
4. प्लगइन परीक्षणों के बारे में मत भूलना। सत्यापित करने के लिए एक परीक्षण जोड़ें कि pytest.ini से nice पैरामीटर सही तरीके pytest.ini काम कर रहा है।
5. प्लगइन निर्देशिका में परीक्षण जोड़ें। आपको कुछ अतिरिक्त पाइस्टर सुविधाओं को खोजने की आवश्यकता है ।

आगे क्या है

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

पीछे अगला