🌺 👩🏽‍💼 🐑 पुस्तक "द वे ऑफ पायथन। विकास, स्केलिंग, परीक्षण और तैनाती के लिए ब्लैक बेल्ट ” ☂️ 🛀🏻 🐊

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

अंश। समानांतर में परीक्षण चल रहा है

रनिंग टेस्ट स्वीट्स समय लेने वाली हो सकती हैं। यह बड़ी परियोजनाओं में एक सामान्य घटना है जब एक परीक्षण सूट को पूरा होने में मिनट लगते हैं। डिफ़ॉल्ट रूप से, एक विशिष्ट क्रम में, pytest क्रमिक रूप से परीक्षण चलाता है।

चूंकि अधिकांश कंप्यूटरों में मल्टी-कोर प्रोसेसर होते हैं, इसलिए यदि आप कई कोर पर चलने के लिए परीक्षणों को अलग करते हैं तो आप गति बढ़ा सकते हैं।

इसके लिए, pytest में एक pytest-xdist प्लगइन है जिसे पाइप का उपयोग करके स्थापित किया जा सकता है। यह प्लगइन pytest कमांड लाइन को -numprocesses (संक्षिप्त-एन) तर्क के साथ विस्तारित करता है, जो एक तर्क के रूप में प्रयुक्त कोर की संख्या लेता है। पाइस्टेस्ट-एन 4 लॉन्च करने से परीक्षण सूट चार समानांतर प्रक्रियाओं में चलेगा, जो उपलब्ध कोर के भार के बीच संतुलन बनाए रखेगा।

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

जुड़नार का उपयोग करके परीक्षण में उपयोग की जाने वाली वस्तुएं बनाना

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

Pytest जुड़नार में सरल कार्य के रूप में घोषित किए जाते हैं। फ़िक्चर फ़ंक्शन को वांछित ऑब्जेक्ट को वापस करना चाहिए ताकि परीक्षण में जहां इसका उपयोग किया जाता है, इस ऑब्जेक्ट का उपयोग किया जा सके।

यहाँ एक साधारण स्थिरता का एक उदाहरण दिया गया है:

import pytest @pytest.fixture def database(): return <some database connection> def test_insert(database): database.insert(123)

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

कोड परीक्षण की एक और आम विशेषता स्थिरता ऑपरेशन के बाद सुपरफ्लस को हटाने की क्षमता है। उदाहरण के लिए, डेटाबेस कनेक्शन बंद करें। एक जनरेटर के रूप में स्थिरता को लागू करना सत्यापित वस्तुओं की सफाई के लिए कार्यक्षमता जोड़ देगा (लिस्टिंग 6.5)।

लिस्टिंग 6.5। एक सत्यापित वस्तु को साफ़ करना
 import pytest @pytest.fixture def database(): db = <some database connection> yield db db.close() def test_insert(database): database.insert(123) 

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

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

 import pytest @pytest.fixture(scope="module") def database(): db = <some database connection> yield db db.close() def test_insert(database): database.insert(123)

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

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

 import os import pytest @pytest.fixture(autouse=True) def change_user_env(): curuser = os.environ.get("USER") os.environ["USER"] = "foobar" yield os.environ["USER"] = curuser def test_user(): assert os.getenv("USER") == "foobar"</source     .  ,    :     ,      ,       . <h3>  </h3>           ,    ,   ,         .          Gnocchi,    . Gnocchi      <i>storage API</i>.    Python          .       ,      API   .        ,      (    storage API),  ,       .   ,   <i> </i>,     ,        .  6.6          ,    :    mysql,   —  postgresql. <blockquote><h4> 6.6.      </h4> <source lang="python">import pytest import myapp @pytest.fixture(params=["mysql", "postgresql"]) def database(request): d = myapp.driver(request.param) d.start() yield d d.stop() def test_insert(database): database.insert("somedata")

चालक स्थिरता एक पैरामीटर के रूप में दो अलग-अलग मान प्राप्त करता है - डेटाबेस ड्राइवरों के नाम जो एप्लिकेशन द्वारा समर्थित हैं। test_insert दो बार चलाया जाता है: एक बार MySQL डेटाबेस के लिए, और दूसरा PostgreSQL डेटाबेस के लिए। इससे एक ही परीक्षा को फिर से लेना आसान हो जाता है, लेकिन विभिन्न परिदृश्यों के साथ, कोड की नई पंक्तियों को जोड़े बिना।

डमी वस्तुओं के साथ प्रबंधित परीक्षण

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

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

मानक लाइब्रेरी में डमी ऑब्जेक्ट बनाने के लिए एक नकली कमांड है। पायथन 3.3 के साथ शुरू, मॉक को unittest.mock लाइब्रेरी के साथ एकीकृत किया गया है। इसलिए, आप पायथन 3.3 और उससे पहले के बीच पिछड़े अनुकूलता प्रदान करने के लिए नीचे दिए गए कोड स्निपेट का उपयोग कर सकते हैं:

 try: from unittest import mock except ImportError: import mock

मॉक लाइब्रेरी का उपयोग करना बहुत आसान है। मॉक के लिए उपलब्ध कोई भी विशेषता। मॉक ऑब्जेक्ट को रनटाइम पर गतिशील रूप से बनाया जाता है। किसी भी विशेषता को किसी भी मूल्य को सौंपा जा सकता है। लिस्टिंग 6.7 में, डॉक विशेषता के लिए डमी ऑब्जेक्ट बनाने के लिए मॉक का उपयोग किया जाता है।

लिस्टिंग 6.7। मॉक एक्सेस करना। मॉक विशेषता
 >>> from unittest import mock >>> m = mock.Mock() >>> m.some_attribute = "hello world" >>> m.some_attribute "hello world" 

आप गतिशील रूप से एक उत्परिवर्तित वस्तु के लिए एक विधि भी बना सकते हैं, जैसे कि लिस्टिंग 6.8 में, जहाँ आप एक ऐसी डमी विधि बनाते हैं जो हमेशा 42 लौटती है और जो कुछ भी आप एक तर्क के रूप में चाहते हैं, ले लेते हैं।

लिस्टिंग 6.8। मॉक के लिए एक विधि बनाना। डॉक डमी ऑब्जेक्ट
 >>> from unittest import mock >>> m = mock.Mock() >>> m.some_method.return_value = 42 >>> m.some_method() 42 >>> m.some_method("with", "arguments") 42 

बस कुछ पंक्तियाँ, और mock.Mock ऑब्जेक्ट में अब कुछ_मिथोड () विधि है, जो 42 रिटर्न करती है। यह किसी भी प्रकार के तर्क को लेती है, जबकि तर्क क्या है, इसका कोई सत्यापन नहीं है।

गतिशील रूप से उत्पन्न विधियां भी (जानबूझकर) दुष्प्रभाव हो सकती हैं। केवल बॉयलरप्लेट के तरीके नहीं हैं जो एक मूल्य लौटाते हैं, उन्हें उपयोगी कोड निष्पादित करने के लिए परिभाषित किया जा सकता है।

6.9 को सूचीबद्ध करने से एक डमी विधि बनती है जिसका साइड इफेक्ट होता है - यह स्ट्रिंग "हैलो वर्ल्ड" को प्रदर्शित करता है।

लिस्टिंग 6.9। एक मॉक के लिए एक विधि बनाना। एक साइड इफेक्ट के साथ मॉक ऑब्जेक्ट
  >>> from unittest import mock >>> m = mock.Mock() >>> def print_hello(): ... print("hello world!") ... return 43 ... ❶ >>> m.some_method.side_effect = print_hello >>> m.some_method() hello world! 43 ❷ >>> m.some_method.call_count 1 

हमने some_method to विशेषता को संपूर्ण फ़ंक्शन सौंपा। तकनीकी रूप से, यह आपको परीक्षण में अधिक जटिल परिदृश्य को लागू करने की अनुमति देता है, इस तथ्य के कारण कि आप डमी ऑब्जेक्ट में परीक्षण के लिए आवश्यक किसी भी कोड को शामिल कर सकते हैं। अगला, आपको इस ऑब्जेक्ट को उस फ़ंक्शन को पास करना होगा जो इसकी अपेक्षा करता है।

To call_count विशेषता को विधि कहा जाता है की संख्या की जांच करने का एक आसान तरीका है।

मॉक लाइब्रेरी "एक्शन-चेक" पैटर्न का उपयोग करती है: इसका मतलब है कि परीक्षण के बाद आपको यह सुनिश्चित करने की आवश्यकता है कि डमी द्वारा प्रतिस्थापित किए गए कार्यों को सही ढंग से निष्पादित किया गया था। इन जाँचों को करने के लिए डमी ऑब्जेक्ट्स में 6.10 लिस्टिंग सूची () को लागू करता है।

लिस्टिंग 6.10। सत्यापन विधियों को कॉल करें

  >>> from unittest import mock >>> m = mock.Mock() ❶ >>> m.some_method('foo', 'bar') <Mock name='mock.some_method()' id='26144272'> ❷ >>> m.some_method.assert_called_once_with('foo', 'bar') >>> m.some_method.assert_called_once_with('foo', ❸mock.ANY) >>> m.some_method.assert_called_once_with('foo', 'baz') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/dist-packages/mock.py", line 846, in assert_cal led_once_with return self.assert_called_with(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/mock.py", line 835, in assert_cal led_with raise AssertionError(msg) AssertionError: Expected call: some_method('foo', 'baz') Actual call: some_method('foo', 'bar')

हमने created पद्धति को कॉल करके परीक्षणों के रूप में फू और बार तर्कों के साथ तरीके बनाए। डमी वस्तुओं पर कॉल का परीक्षण करने का एक आसान तरीका assert_called () विधियों का उपयोग करना है, जैसे कि assert_called_once_with () calls। इन विधियों के लिए, आपको उन मानों को पास करने की आवश्यकता होती है, जिनकी आप डमी पद्धति को कॉल करते समय उपयोग करने की अपेक्षा करते हैं। यदि पास किए गए मानों का उपयोग किए गए लोगों से भिन्न होता है, तो मॉक एसेरेरियनर अपवाद को उठाता है। यदि आप नहीं जानते कि क्या तर्क पारित किए जा सकते हैं, तो mock.ANY का उपयोग what के मान के रूप में करें; यह डमी पद्धति में पारित किसी भी तर्क को प्रतिस्थापित कर देगा।

मॉक लाइब्रेरी का उपयोग किसी बाहरी मॉड्यूल से फ़ंक्शन, विधि या ऑब्जेक्ट को बदलने के लिए भी किया जा सकता है। लिस्टिंग 6.11 में, हमने अपने स्वयं के डमी फ़ंक्शन के साथ os.unlink () फ़ंक्शन को बदल दिया।

लिस्टिंग 6.11। Mock.patch का उपयोग करना

 >>> from unittest import mock >>> import os >>> def fake_os_unlink(path): ... raise IOError("Testing!") ... >>> with mock.patch('os.unlink', fake_os_unlink): ... os.unlink('foobar') ... Traceback (most recent call last): File "<stdin>", line 2, in <module> File "<stdin>", line 2, in fake_os_unlink IOError: Testing!

जब एक संदर्भ प्रबंधक के रूप में उपयोग किया जाता है, तो mock.patch () लक्षित फ़ंक्शन को हमारे द्वारा चुने गए के साथ बदल देता है। यह आवश्यक है ताकि संदर्भ के भीतर निष्पादित कोड सही पद्धति का उपयोग करे। Mock.patch () विधि का उपयोग करके, आप बाहरी कोड के किसी भी भाग को संशोधित कर सकते हैं, इसे इस तरह से व्यवहार करने के लिए मजबूर कर सकते हैं जैसे कि आवेदन के लिए सभी शर्तों का परीक्षण करें (लिस्टिंग 6.12)।

लिस्टिंग 6.12। कई व्यवहारों का परीक्षण करने के लिए mock.patch () का उपयोग करना

  from unittest import mock import pytest import requests class WhereIsPythonError(Exception): pass ❶ def is_python_still_a_programming_language(): try: r = requests.get("http://python.org") except IOError: pass else: if r.status_code == 200: return 'Python is a programming language' in r.content raise WhereIsPythonError("Something bad happened") def get_fake_get(status_code, content): m = mock.Mock() m.status_code = status_code m.content = content def fake_get(url): return m return fake_get def raise_get(url): raise IOError("Unable to fetch url %s" % url) ❷ @mock.patch('requests.get', get_fake_get( 200, 'Python is a programming language for sure')) def test_python_is(): assert is_python_still_a_programming_language() is True @mock.patch('requests.get', get_fake_get( 200, 'Python is no more a programming language')) def test_python_is_not(): assert is_python_still_a_programming_language() is False @mock.patch('requests.get', get_fake_get(404, 'Whatever')) def test_bad_status_code(): with pytest.raises(WhereIsPythonError): is_python_still_a_programming_language() @mock.patch('requests.get', raise_get) def test_ioerror(): with pytest.raises(WhereIsPythonError): is_python_still_a_programming_language()

6.12 को सूचीबद्ध करना एक परीक्षण मामले को लागू करता है जो पायथन के सभी उदाहरणों के लिए दिखता है python.org पर एक प्रोग्रामिंग भाषा स्ट्रिंग है y। ऐसा कोई विकल्प नहीं है जहां परीक्षण चयनित वेब पेज पर कोई दी गई रेखा नहीं मिलेगी। नकारात्मक परिणाम प्राप्त करने के लिए, आपको पृष्ठ बदलने की आवश्यकता है, लेकिन ऐसा नहीं किया जा सकता है। लेकिन नकली की मदद से, आप ट्रिक पर जा सकते हैं और अनुरोध के व्यवहार को बदल सकते हैं ताकि यह एक काल्पनिक पृष्ठ के साथ एक डमी प्रतिक्रिया लौटाए जिसमें एक दिया स्ट्रिंग नहीं है। यह आपको एक नकारात्मक परिदृश्य का परीक्षण करने की अनुमति देगा जिसमें python.org एक दिए गए स्ट्रिंग को शामिल नहीं करता है, और सुनिश्चित करें कि प्रोग्राम ऐसे मामले को सही ढंग से संभालता है।

यह उदाहरण mock.patch () डेकोरेटर संस्करण का उपयोग करता है। डमी ऑब्जेक्ट का व्यवहार नहीं बदलता है, और परीक्षण फ़ंक्शन के संदर्भ में एक उदाहरण सेट करना आसान था।

डमी ऑब्जेक्ट का उपयोग करने से किसी भी समस्या का अनुकरण करने में मदद मिलेगी: सर्वर 404 त्रुटि, I / O त्रुटि या नेटवर्क विलंब त्रुटि देता है। हम यह सुनिश्चित कर सकते हैं कि कोड सही मान लौटाए या प्रत्येक मामले में सही अपवाद फेंके, जो कोड के अपेक्षित व्यवहार की गारंटी देता है।

कवरेज के साथ अनटाइटेड कोड को पहचानें

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

अपने खोल के माध्यम से इसका उपयोग करने में सक्षम होने के लिए पाइप के माध्यम से कवरेज मॉड्यूल स्थापित करें।

नोट

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

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

पाइस्टेस्ट का उपयोग करते समय, पाइस्ट-कोव प्लगइन को पिप इंस्टॉल पाइस्ट-पाइकोव के माध्यम से स्थापित करें और अनटाइटेड कोड (लिस्टिंग 6.13) का विस्तृत आउटपुट उत्पन्न करने के लिए कुछ स्विच जोड़ें।

लिस्टिंग 6.13। पाइस्टेस्ट और कवरेज का उपयोग करना

 $ pytest --cov=gnocchiclient gnocchiclient/tests/unit ---------- coverage: platform darwin, python 3.6.4-final-0 ----------- Name Stmts Miss Branch BrPart Cover --------------------------- gnocchiclient/__init__.py 0 0 0 0 100% gnocchiclient/auth.py 51 23 6 0 49% gnocchiclient/benchmark.py 175 175 36 0 0% --snip-- --------------------------- TOTAL 2040 1868 424 6 8% === passed in 5.00 seconds ===

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

कवरेज मॉड्यूल और भी बेहतर है - यह आपको HTML प्रारूप में स्पष्ट रिपोर्ट उत्पन्न करने की अनुमति देता है। बस जोड़ें -cov-report-html और HTML पृष्ठ htmlcov निर्देशिका में दिखाई देंगे जहाँ से आप कमांड चलाते हैं। प्रत्येक पृष्ठ दिखाएगा कि स्रोत कोड के कौन से भाग थे या नहीं चल रहे थे।

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

उदाहरण के लिए, कोड को 100% परीक्षण के साथ कवर करना एक योग्य लक्ष्य है, लेकिन इसका मतलब यह नहीं है कि कोड पूरी तरह से परीक्षण किया गया है। यह मान केवल दिखाता है कि प्रोग्राम में कोड की सभी पंक्तियों को पूरा किया गया है, लेकिन यह इंगित नहीं करता है कि सभी शर्तों का परीक्षण किया गया है।

परीक्षण सूट का विस्तार करने और कोड के लिए उन्हें बनाने के लिए कवरेज जानकारी का उपयोग करने के लायक है जो नहीं चलता है। यह परियोजना समर्थन को सरल करता है और समग्र कोड गुणवत्ता में सुधार करता है।

लेखक के बारे में

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

साइंस एडिटर के बारे में

माइक ड्रिसकॉल पायथन में एक दशक से अधिक समय से प्रोग्रामिंग कर रहे हैं। लंबे समय तक, उन्होंने द माउस बनाम पाइथन के बारे में लिखा । अजगर । कई पायथन पुस्तकों के लेखक: पायथन 101, पायथन इंटरव्यू और रिपोर्टलैब: पीडीएफ प्रोसेसिंगवीथ पायथन। आप ट्विटर पर और GitHub: @driscollis पर माइक पा सकते हैं।

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर उपलब्ध है
» सामग्री
» अंश

फेरीवालों के लिए कूपन पर 25% की छूट - पायथन

पुस्तक के पेपर संस्करण के भुगतान पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजी जाती है।

पुस्तक "द वे ऑफ पायथन। विकास, स्केलिंग, परीक्षण और तैनाती के लिए ब्लैक बेल्ट ”

अंश। समानांतर में परीक्षण चल रहा है

जुड़नार का उपयोग करके परीक्षण में उपयोग की जाने वाली वस्तुएं बनाना

लिस्टिंग 6.5। एक सत्यापित वस्तु को साफ़ करना

डमी वस्तुओं के साथ प्रबंधित परीक्षण

लिस्टिंग 6.7। मॉक एक्सेस करना। मॉक विशेषता

लिस्टिंग 6.8। मॉक के लिए एक विधि बनाना। डॉक डमी ऑब्जेक्ट

लिस्टिंग 6.9। एक मॉक के लिए एक विधि बनाना। एक साइड इफेक्ट के साथ मॉक ऑब्जेक्ट