😄 🥙 💆🏿 परीक्षण Django परियोजनाओं ⛹🏻 🤹 👟

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

पद का सारांश:

वेबसाइट परीक्षण कठिन और समझ से बाहर है
django में यूनिट परीक्षण
डेटाबेस का परीक्षण करें और इससे कैसे निपटें
धूम्रपान परीक्षण
कोड कवरेज

वेबसाइट परीक्षण

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

इसलिए, वेबसाइट के प्रदर्शन की जांच करना आमतौर पर एक जटिल घटना है, जिसमें कई स्वतंत्र परीक्षण सूट शामिल हैं, जिनमें से कुछ (उदाहरण के लिए विभिन्न ब्राउज़रों में उपस्थिति की जाँच करना) ऑपरेटर की भागीदारी को शामिल कर सकते हैं। क्यूए विभाग की अनुपस्थिति में, परीक्षक की भूमिका अक्सर अंतिम उपयोगकर्ता को सौंपी जाती है, जो तब हर संभव तरीके से शपथ लेता है। तो गलत करो। _{कर्नल एविडेंस पोस्ट पास हुआ।}

हम (अपेक्षाकृत) सरल और सहज इकाई परीक्षणों के साथ शुरू करते हैं।

Django में यूनिट टेस्ट

Django में यूनिट परीक्षण django.utils.unittest मॉड्यूल में रहते हैं और अजगर 2.7 (unittest2) से मानक unittest मॉड्यूल का विस्तार हैं। क्या जोड़ा गया है:

HTTP क्लाइंट का परीक्षण करें। यह ब्राउज़र के संचालन का अनुकरण करता है, कॉल के बीच कुकीज़ बचाता है, अनुरोध और पोस्ट-अनुरोध भेज सकता है।

 >>> from django.test.client import Client >>> c = Client() >>> response = c.post('/login/', {'username': 'admin', 'password': 'qwerty'}) >>> response.status_code 200

परीक्षण क्लाइंट के लिए कई सीमाएँ हैं। उदाहरण के लिए, आप केवल एक सापेक्ष पथ का अनुरोध कर सकते हैं, फॉर्म का एक URL http: / / / localhost: 8000 / काम नहीं करेगा (स्पष्ट रूप से)।

चेक का विस्तृत सेट। मानक सेट के अलावा, django.test.TestCase क्लास में django-specific assert* विधियाँ django.test.TestCase शामिल हैं, उदाहरण के लिए:

 assertContains(response, text, ...) # ,       ; assertTemplateUsed(response, template_name, ...) # ,       ; assertRedirects(response, expected_url, ...) # ,   ;

और अन्य उपयोगी चीजें ।

परीक्षण मेल। Django.core.mail मॉड्यूल आउटबॉक्स वैरिएबल में send_mail() माध्यम से भेजे send_mail() सभी send_mail() की एक सूची बचाता है।

सशर्त परीक्षण अपवाद। यदि चयनित DBMS ट्रांजेक्शनलिटी का समर्थन नहीं करता (या, इसके विपरीत, समर्थन करता है), तो आप @skipUnlessDBFeature('supports_transactions') या @skipIfDBFeature('supports_transactions') डेकोरेटर का उपयोग करके जानबूझकर टूटे हुए परीक्षणों को बाहर कर सकते हैं।

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

 $ ./manage.py test [ ]

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

 from utils import func_a, func_b __test__ = {"func_a": func_a, "func_b": func_b}

यहाँ func_* एक फ़ंक्शन (या अन्य इकाई) है जिसका डॉकस्ट्रिंग हमारे हित में है।

पर्यवेक्षक के लिए, परीक्षण प्रक्रिया इस प्रकार है:

 $ ./manage.py test main Creating test database for alias 'default'... .......... Ran 10 tests in 0.790s OK Destroying test database for alias 'default'...

डीबी का परीक्षण करें और इससे कैसे निपटें

परीक्षण चलाने के लिए, Django हमेशा काम के माहौल में डेटा विनाश की संभावना को खत्म करने के लिए एक नया डेटाबेस बनाता है। जब तक अन्यथा सेटिंग्स में निर्दिष्ट नहीं किया जाता है, परीक्षण डेटाबेस शब्द test_ से पहले होता है। MySQL पर लागू होता है, विशेषाधिकार आमतौर पर किसी तरह इस तरह निर्धारित होते हैं:

 GRANT ALL PRIVILEGES ON `project`.* TO 'user'@'localhost'; GRANT ALL PRIVILEGES ON `test_project`.* TO 'user'@'localhost';

यह test_project डेटाबेस बनाने के लिए आवश्यक नहीं है।

मालकिन नोट यदि आप MySQL कॉन्फ़िगरेशन में लाइन जोड़ते हैं तो सब कुछ तेज़ी से काम करता है

 [mysqld] skip-sync-frm=OFF

यह सट्टा है कि डेटाबेस में कोई उपयोगी डेटा बनाने के तुरंत बाद। प्रत्येक परीक्षण के अंदर अलग से सेट किए गए एक परीक्षण डेटा को उत्पन्न करने के लिए नहीं, आप इसे एक बार कर सकते हैं और इसे स्थिरता में सहेज सकते हैं:

 $ ./manage.py dumpdata > app/fixtures/test_data.json

कोड में:

 class HelloTestCase(TestCase): fixtures = ['test_data.json', 'moar_data.json']

और अधिक। उत्पादन सर्वर पर विकास और परीक्षण के लिए समान DBMS का उपयोग करने का प्रयास करें। इससे आपकी नींद 28% ^* शांत हो जाएगी।

_{* वैज्ञानिक रूप से सिद्ध है कि 87.56% आँकड़े छत से लिए गए हैं।}

धुआँ परीक्षण

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

वर्णित दृष्टिकोण भी अनुप्रयोगों का परीक्षण करते समय अभ्यास किया जाता है। Django के लिए लागू किया गया है, यह test.py में प्रविष्टि.confs का वर्णन करने के लिए समझ में आता है, जैसे:

urls.py

 urlpatterns = patterns(None, url(r'^registration/$', registration, name='registration'), url(r'^login/$', ..., name='login'), url(r'^logout/$', logout_then_login, name='logout'), )

tests.py

 from django import test from django.core.urlresolvers import reverse __test__ = {"urls": """ >>> c = test.Client() >>> c.get(reverse('registration')).status_code 200 >>> c.get(reverse('login')).status_code 200 >>> c.get(reverse('logout')).status_code 302 """}

बेशक, ऐसा चेक पंजीकरण और लॉगिन के कार्यात्मक परीक्षण को प्रतिस्थापित नहीं करेगा। _{कर्नल साक्ष्य पद स्वीकृत।}

कोड कवरेज

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

नोट -2 पर मालकिन कोड के उच्च कवरेज का मतलब यह नहीं है कि कोई त्रुटि नहीं है (न तो कोड में, न ही परीक्षणों में), यह कल्पना है।

पायथन में कोड कवरेज को मापने के लिए कवरेज थ्रीडी है। Google दोस्तों को मित्रों को Oracle और Django बनाने के कई प्रयासों को याद करता है, यहां तक कि टिकट # 4501 (वह चार साल का है) है।

और तुरंत मरहम में उड़ना: Django 1.3 (और देव संस्करण) के साथ, कोड कवरेज के लिए कोई भी तैयार समाधान काम नहीं करता है (मुझे ठीक करें अगर यह नहीं है)। हालांकि, यह हमें अपने हाथों से कवरेज थिंकपैड लॉन्च करने से नहीं रोकेगा।

 $ coverage run --source=main,users manage.py test main users $ coverage html #

हम केवल उन मॉड्यूल को सूचीबद्ध करते हैं जो हमारी रुचि रखते हैं (- स्रोत स्विच); यदि निर्दिष्ट नहीं है, तो django, mysqldb और मानक अजगर आपूर्ति का आधा शामिल होगा।

उसके बाद, htmlcov फ़ोल्डर (डिफ़ॉल्ट पथ) में, आप कोड की प्रत्येक पंक्ति, मॉड्यूल द्वारा कवरेज और परियोजना द्वारा कुल पर एक विस्तृत रिपोर्ट देख सकते हैं।

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

परीक्षण Django परियोजनाओं

वेबसाइट परीक्षण

Django में यूनिट टेस्ट

डीबी का परीक्षण करें और इससे कैसे निपटें

धुआँ परीक्षण

कोड कवरेज

More articles: