पायथन के साथ पायथन परीक्षण। अन्य उपकरणों के साथ pytest का उपयोग करना, अध्याय 7

वापसी

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

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

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

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

pdb: डिबगिंग टेस्ट में विफलता

pdb मॉड्यूल मानक पुस्तकालय में पायथन डिबगर है। आप --pdb उपयोग --pdb ताकि pytest विफलता के बिंदु पर डिबगिंग सत्र शुरू करे। आइए टास्क प्रोजेक्ट के संदर्भ में क्रिया में pdb ।

64 पृष्ठ पर "पैरामीटर फिक्सिंग" में, हमने कुछ त्रुटियों के साथ टास्क परियोजना को छोड़ दिया:

 $ cd /path/to/code/ch3/c/tasks_proj $ pytest --tb=no -q .........................................FF.FFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.FFF........... 42 failed, 54 passed in 4.74 seconds 

इससे पहले कि हम देखें कि pdb हमें इस परीक्षण को डिबग करने में कैसे मदद कर सकता है, आइए परीक्षण त्रुटियों की डीबगिंग को गति देने के लिए उपलब्ध सबसे अच्छे विकल्पों पर एक नज़र डालें, जिसे हमने पहले पृष्ठ 9 पर "विकल्प का उपयोग करते हुए" अनुभाग में जांच की थी:

• --tb=[auto/long/short/line/native/no] : ट्रेस स्टाइल को नियंत्रित करता है।
• -v / --verbose : उन सभी परीक्षण नामों को प्रदर्शित करता है जो पास या असफल हुए।
• -l / --showlocals : स्टैक ट्रेस के आगे स्थानीय चर प्रदर्शित करता है।
• -lf / --last-failed : केवल परीक्षण विफल रहता है।
• -x / --exitfirst : पहली विफलता पर परीक्षण सत्र -x / --exitfirst ।
• --pdb : विफलता के बिंदु पर एक इंटरैक्टिव डिबगिंग सत्र शुरू करता है।

MongoDB स्थापित करना

जैसा कि अध्याय 3 में उल्लेख किया गया है, पेज 49 पर “पाइस्टेस्ट फिक्स्चर”, MongoDB और pymongo स्थापना को MongoDB परीक्षण चलाने की आवश्यकता है।

मैंने https://www.mongodb.com/download-center पर पाए गए सामुदायिक सर्वर के संस्करण का परीक्षण किया। पाइप के साथ pymongo स्थापित: pip install pymongo । हालाँकि, यह एक पुस्तक में अंतिम उदाहरण है जो MongoDB का उपयोग करता है। MongoDB का उपयोग किए बिना डिबगर को आज़माने के लिए, आप code/ch2/ से pytest कमांड चला सकते हैं, क्योंकि इस निर्देशिका में कई विफल परीक्षण भी शामिल हैं।

हमने code/ch3/c से परीक्षण केवल यह सुनिश्चित करने के लिए चलाया कि उनमें से कुछ काम नहीं कर रहे हैं। हमने ट्रेसबैक या परीक्षण नाम नहीं देखे क्योंकि --tb=no अनुरेखण नहीं है और हमारे पास --verbose सक्षम नहीं है। आइए विस्तृत पाठ के साथ त्रुटियों को दोहराएं (तीन से अधिक नहीं):

 $ pytest --tb=no --verbose --lf --maxfail=3 ============================= test session starts ============================= collected 96 items / 52 deselected run-last-failure: rerun previous 44 failures tests/func/test_add.py::test_add_returns_valid_id[mongo] ERROR [ 2%] tests/func/test_add.py::test_added_task_has_id_set[mongo] ERROR [ 4%] tests/func/test_add.py::test_add_increases_count[mongo] ERROR [ 6%] =================== 52 deselected, 3 error in 0.72 seconds ==================== 

अब हम जानते हैं कि कौन से परीक्षण विफल रहे। चलो उनमें से सिर्फ एक का उपयोग करते हैं, -x का उपयोग करते हुए, ट्रेसिंग चालू करते हैं, --tb=no का उपयोग नहीं करते हैं, और -l साथ स्थानीय चर दिखाते हैं:

 $ pytest -v --lf -l -x ===================== test session starts ====================== run-last-failure: rerun last 42 failures collected 96 items tests/func/test_add.py::test_add_returns_valid_id[mongo] FAILED =========================== FAILURES =========================== _______________ test_add_returns_valid_id[mongo] _______________ tasks_db = None def test_add_returns_valid_id(tasks_db): """tasks.add(<valid task>) should return an integer.""" # GIVEN an initialized tasks db # WHEN a new task is added # THEN returned task_id is of type int new_task = Task('do something') task_id = tasks.add(new_task) > assert isinstance(task_id, int) E AssertionError: assert False E + where False = isinstance(ObjectId('59783baf8204177f24cb1b68'), int) new_task = Task(summary='do something', owner=None, done=False, id=None) task_id = ObjectId('59783baf8204177f24cb1b68') tasks_db = None tests/func/test_add.py:16: AssertionError !!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!! ===================== 54 tests deselected ====================== =========== 1 failed, 54 deselected in 2.47 seconds ============ 

काफी बार यह समझने के लिए पर्याप्त है कि परीक्षण विफल क्यों हुआ। इस विशेष मामले में, यह बहुत स्पष्ट है कि task_id पूर्णांक नहीं है - यह ObjectId का एक उदाहरण है। ObjectId डेटाबेस में ऑब्जेक्ट पहचानकर्ताओं के लिए MongoDB द्वारा उपयोग किया जाने वाला प्रकार है। tasksdb_pymongo.py लेयर के साथ मेरा इरादा बाकी सिस्टम से MongoDB कार्यान्वयन के कुछ विवरणों को छिपाना था। यह स्पष्ट है कि इस मामले में यह काम नहीं किया।

हालाँकि, हम यह देखना चाहते हैं कि pdb का उपयोग pytest के साथ कैसे किया जाए, तो चलिए कल्पना करते हैं कि यह स्पष्ट नहीं है कि यह परीक्षण विफल क्यों हुआ। हम pytest को एक डिबगिंग सत्र शुरू कर सकते हैं और हमें सही विफलता के बिंदु पर शुरू कर सकते हैं --pdb का उपयोग कर

 $ pytest -v --lf -x --pdb ===================== test session starts ====================== run-last-failure: rerun last 42 failures collected 96 items tests/func/test_add.py::test_add_returns_valid_id[mongo] FAILED >>>>>>>>>>>>>>>>>>>>>>>>>> traceback >>>>>>>>>>>>>>>>>>>>>>>>>>> tasks_db = None def test_add_returns_valid_id(tasks_db): """tasks.add(<valid task>) should return an integer.""" # GIVEN an initialized tasks db # WHEN a new task is added # THEN returned task_id is of type int new_task = Task('do something') task_id = tasks.add(new_task) > assert isinstance(task_id, int) E AssertionError: assert False E + where False = isinstance(ObjectId('59783bf48204177f2a786893'), int) tests/func/test_add.py:16: AssertionError >>>>>>>>>>>>>>>>>>>>>>>>> entering PDB >>>>>>>>>>>>>>>>>>>>>>>>> > /path/to/code/ch3/c/tasks_proj/tests/func/test_add.py(16) > test_add_returns_valid_id() -> assert isinstance(task_id, int) (Pdb) 

अब हम प्रांप्ट (Pdb) पर हैं, हमारे पास सभी इंटरैक्टिव pdb डीबगिंग सुविधाओं तक पहुँच है। क्रैश देखते समय, मैं नियमित रूप से इन कमांड का उपयोग करता हूं:

• p/print expr : exp के मूल्य को प्रिंट करता है।
• pp expr : सुंदर pp expr के मूल्य प्रिंट।
• l/list : विफलता के बिंदु और ऊपर और नीचे कोड की पांच पंक्तियों को सूचीबद्ध करता है।
• l/list begin,end : विशिष्ट लाइन संख्या की गणना करता है।
• a/args : वर्तमान फ़ंक्शन के तर्कों को उनके मूल्यों के साथ प्रिंट करता है।
• u/up : स्टैक पथ को एक स्तर ऊपर ले जाता है।
• d/down : स्टैक ट्रेस में एक स्तर नीचे ले जाता है।
• q/quit : एक डिबगिंग सत्र समाप्त करता है।

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

आप किसी फ़ंक्शन में मानों को देखने के लिए p/print expr -l/--showlocals समान उपयोग कर सकते हैं:

 (Pdb) p new_task Task(summary='do something', owner=None, done=False, id=None) (Pdb) p task_id ObjectId('59783bf48204177f2a786893') (Pdb) 

अब आप डिबगर से बाहर निकल सकते हैं और परीक्षण जारी रख सकते हैं।

 (Pdb) q !!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!! ===================== 54 tests deselected ====================== ========== 1 failed, 54 deselected in 123.40 seconds =========== 

अगर हमने - उपयोग नहीं किया, तो अगले टेस्ट में pytb फिर से Pdb खोलेगा। Pdb मॉड्यूल का उपयोग करने के बारे में अधिक जानकारी पायथन प्रलेखन में उपलब्ध है।

Coverage.py: परीक्षण कोड की मात्रा का निर्धारण

कोड कवरेज परीक्षण कोड के प्रतिशत का एक संकेतक है जो परीक्षणों के एक सेट द्वारा परीक्षण किया जाता है। जब आप कार्य प्रोजेक्ट के लिए परीक्षण चलाते हैं, तो कुछ कार्य प्रत्येक परीक्षण के साथ निष्पादित किए जाते हैं, लेकिन सभी के साथ नहीं।

कोड कवरेज उपकरण आपको यह बताने के लिए बहुत अच्छे हैं कि सिस्टम के कौन से हिस्से पूरी तरह से परीक्षणों द्वारा अनदेखे हैं।

Coverage.py एक पसंदीदा पाइथन कवरेज टूल है जो कोड कवरेज को मापता है।

आप इसका उपयोग कार्य प्रोजेक्ट कोड को पाइस्टेस्ट के साथ सत्यापित करने के लिए करेंगे।

नंबर का उपयोग करने के लिए आपको इसे इंस्टॉल करना होगा। यह pytest-cov नामक एक प्लगइन को स्थापित करने के लिए चोट नहीं pytest-cov , जो आपको कुछ अतिरिक्त pytest विकल्पों के साथ pytest से coverage.py ओरेकल को कॉल करने की अनुमति देता है। चूंकि coverage pytest-cov की निर्भरता में से एक है, बस pytest-cov स्थापित करें और यह coverage.py pytest-cov ले जाएगा:

 $ pip install pytest-cov Collecting pytest-cov Using cached pytest_cov-2.5.1-py2.py3-none-any.whl Collecting coverage>=3.7.1 (from pytest-cov) Using cached coverage-4.4.1-cp36-cp36m-macosx_10_10_x86 ... Installing collected packages: coverage, pytest-cov Successfully installed coverage-4.4.1 pytest-cov-2.5.1 

चलो दूसरे कार्य संस्करण के लिए कवरेज रिपोर्ट चलाते हैं। यदि आपके पास अभी भी टास्क प्रोजेक्ट का पहला संस्करण स्थापित है, तो इसे अनइंस्टॉल करें और संस्करण 2 स्थापित करें:

 $ pip uninstall tasks Uninstalling tasks-0.1.0: /path/to/venv/bin/tasks /path/to/venv/lib/python3.6/site-packages/tasks.egg-link Proceed (y/n)? y Successfully uninstalled tasks-0.1.0 $ cd /path/to/code/ch7/tasks_proj_v2 $ pip install -e . Obtaining file:///path/to/code/ch7/tasks_proj_v2 ... Installing collected packages: tasks Running setup.py develop for tasks Successfully installed tasks $ pip list ... tasks (0.1.1, /path/to/code/ch7/tasks_proj_v2/src) ... 

अब जब कार्यों का अगला संस्करण स्थापित हो गया है, तो आप आधार कवरेज रिपोर्ट चला सकते हैं:

 $ cd /path/to/code/ch7/tasks_proj_v2 $ pytest --cov=src ===================== test session starts ====================== plugins: mock-1.6.2, cov-2.5.1 collected 62 items tests/func/test_add.py ... tests/func/test_add_variety.py ............................ tests/func/test_add_variety2.py ............ tests/func/test_api_exceptions.py ......... tests/func/test_unique_id.py . tests/unit/test_cli.py ..... tests/unit/test_task.py .... ---------- coverage: platform darwin, python 3.6.2-final-0 ----------- Name Stmts Miss Cover -------------------------------------------------- src\tasks\__init__.py 2 0 100% src\tasks\api.py 79 22 72% src\tasks\cli.py 45 14 69% src\tasks\config.py 18 12 33% src\tasks\tasksdb_pymongo.py 74 74 0% src\tasks\tasksdb_tinydb.py 32 4 88% -------------------------------------------------- TOTAL 250 126 50% ================== 62 passed in 0.47 seconds =================== 

चूँकि वर्तमान निर्देशिका tasks_proj_v2 , और परीक्षण के तहत स्रोत कोड src में है, --cov=src विकल्प को जोड़ने से परीक्षण के तहत केवल इस निर्देशिका के लिए एक कवरेज रिपोर्ट उत्पन्न होती है।

जैसा कि आप देख सकते हैं, कुछ फ़ाइलों में काफी कम और यहां तक ​​कि 0% कवरेज है। ये उपयोगी रिमाइंडर हैं: tasksdb_pymongo.py 0% क्योंकि हमने इस संस्करण में MongoDB के लिए परीक्षण अक्षम कर दिया है। उनमें से कुछ काफी कम हैं। परियोजना निश्चित रूप से प्राइम टाइम के लिए तैयार होने से पहले इन सभी क्षेत्रों के लिए परीक्षण वितरित करना होगा।

मेरा मानना ​​है कि कई फ़ाइलों में कवरेज का प्रतिशत अधिक है: api.py और tasksdb_tinydb.py । आइए tasksdb_tinydb.py पर एक नज़र tasksdb_tinydb.py और देखें कि क्या गायब है। मुझे लगता है कि ऐसा करने का सबसे अच्छा तरीका HTML रिपोर्ट का उपयोग करना है।

यदि आप फिर से - --cov-report=html विकल्प के साथ एक बार फिर से काम करते हैं, तो एक --cov-report=html उत्पन्न होगी:

 $ pytest --cov=src --cov-report=html ===================== test session starts ====================== plugins: mock-1.6.2, cov-2.5.1 collected 62 items tests/func/test_add.py ... tests/func/test_add_variety.py ............................ tests/func/test_add_variety2.py ............ tests/func/test_api_exceptions.py ......... tests/func/test_unique_id.py . tests/unit/test_cli.py ..... tests/unit/test_task.py .... ---------- coverage: platform darwin, python 3.6.2-final-0 ----------- Coverage HTML written to dir htmlcov ================== 62 passed in 0.45 seconds =================== 

आप निम्न स्क्रीन पर आउटपुट प्रदर्शित करने वाले ब्राउज़र में htmlcov/index.html खोल सकते हैं:

tasksdb_tinydb.py पर क्लिक करने से एक फ़ाइल के लिए एक रिपोर्ट प्रदर्शित होगी। कवर की गई लाइनों का प्रतिशत रिपोर्ट के शीर्ष पर प्रदर्शित होता है, साथ ही कितनी लाइनें कवर की जाती हैं और कितनी नहीं होती हैं, जैसा कि अगले भाग में दिखाया गया है:

नीचे स्क्रॉल करते हुए, आप लापता लाइनों को देख सकते हैं, जैसा कि निम्नलिखित स्क्रीन में दिखाया गया है:

भले ही यह स्क्रीन इस फ़ाइल के लिए पूर्ण पृष्ठ नहीं है, यह हमें यह बताने के लिए पर्याप्त है:

1. हम स्वामी के सेट के साथ list_tasks() परीक्षण नहीं करते हैं।
2. हम update() या delete() परीक्षण नहीं करते हैं।
3. शायद हम unique_id() पूरी तरह से परीक्षण नहीं कर रहे हैं।

बहुत बढ़िया। हम उन्हें विन्यास प्रणाली के परीक्षण के साथ-साथ हमारी TO-DO परीक्षण सूची में शामिल कर सकते हैं।

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

अधिक जानकारी के coverage.py pytest-cov और pytest-cov coverage.py देखें।

नकली: सिस्टम भागों का प्रतिस्थापन

मॉक पैकेज का उपयोग सिस्टम के कुछ हिस्सों को बदलने के लिए किया जाता है ताकि बाकी कोड से टेस्ट कोड के कुछ हिस्सों को अलग किया जा सके। मॉक - वस्तुओं को कभी-कभी टेस्ट डबल्स, जासूस, फेक या स्टब्स कहा जाता है।

अपने स्वयं के पाइस्टेस्ट मंकीपैक स्थिरता (पृष्ठ 85 पर मंकीपैच का उपयोग करने में वर्णित) और नकली के बीच, आपके पास सभी आवश्यक दोहरी परीक्षण कार्यक्षमता होनी चाहिए।

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

mock पैकेज मानक पायथन लाइब्रेरी के साथ आता है, जैसे कि पायथन 3.3 के बाद से unittest.mock । पहले के संस्करणों में, यह PyPI के माध्यम से स्थापित एक अलग पैकेज के रूप में उपलब्ध है। इसका मतलब है कि आप पायथन 2.6 से लेटेस्ट पायथन संस्करण में mock पायपीआई संस्करण का उपयोग कर सकते हैं और नवीनतम mock पायथन के समान कार्यक्षमता पा सकते हैं। हालांकि, pytest के साथ उपयोग के लिए, pytest-mock नामक एक प्लगइन में कुछ विशेषताएं हैं जो इसे मॉक सिस्टम के लिए मेरा पसंदीदा इंटरफ़ेस बनाती हैं।

टास्क प्रोजेक्ट के लिए, हम कमांड लाइन इंटरफ़ेस का परीक्षण करने में हमारी सहायता के लिए mock का उपयोग करेंगे। Coverage.py में: यह निर्धारित करके कि कोड कितना परीक्षण किया जा रहा है, पृष्ठ 129 पर आपने देखा कि हमारी cli.py फ़ाइल का परीक्षण बिल्कुल नहीं किया गया था। हम इसे अब ठीक करना शुरू करेंगे। लेकिन पहले रणनीति के बारे में बात करते हैं।

टास्क परियोजना में पहला समाधान api.py माध्यम से api.py कार्यक्षमता परीक्षण करना था। इसलिए, एक उचित समाधान यह है कि कमांड लाइन परीक्षण का पूर्ण कार्यात्मक परीक्षण होना आवश्यक नहीं है। हम यह सुनिश्चित कर सकते हैं कि अगर हम सीएलआई परीक्षण के दौरान गीला एपीआई स्तर प्राप्त करते हैं तो सिस्टम सीएलआई के माध्यम से काम करेगा। यह एक सुविधाजनक समाधान भी है जो हमें इस खंड में मोकी को देखने की अनुमति देता है।

CLI कार्य कार्यान्वयन थर्ड-पार्टी क्लिक कमांड लाइन इंटरफ़ेस पैकेज का उपयोग करता है। कमांड लाइन इंटरफ़ेस को लागू करने के लिए कई विकल्प हैं, जिसमें पायथन argparse में निर्मित मॉड्यूल भी शामिल है। मेरे द्वारा क्लिक को चुनने का एक कारण यह है कि इसमें एक परीक्षण इंजन शामिल है जो हमें क्लिक अनुप्रयोगों का परीक्षण करने में मदद करता है। हालाँकि, cli.py में कोड, हालाँकि हमें उम्मीद है कि क्लिक एप्लिकेशन की खासियत है, स्पष्ट नहीं है।

चलो धीमा करें और कार्य के तीसरे संस्करण को स्थापित करें:

 $ cd /path/to/code/ $ pip install -e ch7/tasks_proj_v2 ... Successfully installed tasks 

इस खंड के शेष भाग में, आप "सूची" की कार्यक्षमता का परीक्षण करने के लिए कई परीक्षण विकसित करेंगे।
आइए इसे कार्रवाई में देखें कि हम क्या जाँच करने जा रहे हैं:

अनुवादक नोट: विंडोज प्लेटफॉर्म का उपयोग करते समय, नीचे दिए गए सत्र का परीक्षण करते समय मुझे कई समस्याओं का सामना करना पड़ा।

1. आपके उपयोगकर्ता के फ़ोल्डर में tasks_db नाम के डेटाबेस के लिए एक फ़ोल्डर बनाया जाना चाहिए। उदाहरण के लिए c:\Users\User_1\tasks_db\
   अन्यथा, हम प्राप्त करते हैं - >> FileNotFoundError: [Errno 2] ऐसी कोई फ़ाइल या निर्देशिका नहीं: 'c: \ Users \ User_1 // कार्य_db // कार्य_db.json'
2. एपोस्ट्रोफ के बजाय दोहरे उद्धरण चिह्नों का उपयोग करें। अन्यथा त्रुटि मिलती है
   'कुछ महान करो'
   उपयोग: कार्य जोड़ते हैं [विकल्प] सारांश
   मदद के लिए "कार्यों को जोड़ने -h" का प्रयास करें।
   
   त्रुटि: अनपेक्षित अतिरिक्त तर्क (कुछ महान ')
   

 $ tasks list ID owner done summary -- ----- ---- ------- $ tasks add 'do something great' $ tasks add "repeat" -o Brian $ tasks add "again and again" --owner Okken $ tasks list ID owner done summary -- ----- ---- ------- 1 False do something great 2 Brian False repeat 3 Okken False again and again $ tasks list -o Brian ID owner done summary -- ----- ---- ------- 2 Brian False repeat $ tasks list --owner Brian ID owner done summary -- ----- ---- ------- 2 Brian False repeat 

यह बहुत सरल लगता है। tasks list कमांड हेडिंग के तहत सभी कार्यों की सूची प्रदर्शित करता है।
सूची खाली होने पर भी शीर्षक मुद्रित होता है। कमांड केवल एक मालिक का डेटा प्रदर्शित करता है, अगर -o या --owner । और हम इसे कैसे जांचें? कई तरीके हैं, लेकिन हम मोकी का उपयोग करने जा रहे हैं।

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

ch7 / task_proj_v2 / src / कार्यों / cli.py

 if __name__ == '__main__': tasks_cli() 

यह कार्य करने के लिए सिर्फ एक कॉल tasks_cli() :

ch7 / task_proj_v2 / src / कार्यों / cli.py

 @click.group(context_settings={'help_option_names': ['-h', '--help']}) @click.version_option(version='0.1.1') def tasks_cli(): """Run the tasks application.""" pass 

जाहिर है? नहीं। लेकिन रुकिए, यह आपके दृष्टिकोण के आधार पर अच्छा (या बुरा) हो जाता है। यहाँ list आदेशों में से एक है:

ch7 / task_proj_v2 / src / कार्यों / cli.py

 @tasks_cli.command(name="list", help="list tasks") @click.option('-o', '--owner', default=None, help='list tasks with this owner') def list_tasks(owner): """    .   ,      . """ formatstr = "{: >4} {: >10} {: >5} {}" print(formatstr.format('ID', 'owner', 'done', 'summary')) print(formatstr.format('--', '-----', '----', '-------')) with _tasks_db(): for t in tasks.list_tasks(owner): done = 'True' if t.done else 'False' owner = '' if t.owner is None else t.owner print(formatstr.format( t.id, owner, done, t.summary)) 

जब आपको क्लिक कोड लिखने की आदत हो, तो सुनिश्चित करें कि यह कोड इतना बुरा नहीं है। मैं यहां इस फ़ंक्शन में क्या और कैसे काम करता हूं, यह समझाने वाला नहीं हूं, क्योंकि कमांड-लाइन कोड का विकास पुस्तक का फोकस नहीं है; हालाँकि, मैं लगभग पूरी तरह से आश्वस्त हूं कि मेरे पास यह सही कोड है, वैसे भी, मानव त्रुटि के लिए हमेशा बहुत जगह है। इसीलिए यह सुनिश्चित करने के लिए कि यह सुविधा सही ढंग से काम करती है, स्वचालित परीक्षणों का एक अच्छा सेट महत्वपूर्ण है।
यह list_tasks(owner) कार्य list_tasks(owner) फ़ंक्शन कई अन्य कार्यों पर निर्भर करता है: tasks_db() , जो कि संदर्भ प्रबंधक है, और tasks.list_tasks(owner) , जो API फ़ंक्शन है।

हम tasks_db() और कार्यों के लिए नकली कार्यों को लगाने के लिए mock का उपयोग करने जा रहे हैं। फिर हम कमांड लाइन इंटरफ़ेस के माध्यम से list_tasks पद्धति को कॉल कर सकते हैं और यह सुनिश्चित कर सकते हैं कि यह फ़ंक्शन tasks.list_tasks() फ़ंक्शन को कॉल करती है, जो सही तरीके से काम करती है और सही ढंग से रिटर्न मान संसाधित करती है।
tasks_db() बाहर tasks_db() , आइए एक वास्तविक कार्यान्वयन देखें:

वापसी