Django 2.1 - Testing tools

परीक्षण उपकरण




django

परीक्षण उपकरण

Django एक छोटा सा उपकरण प्रदान करता है जो परीक्षण लिखते समय काम आता है।

परीक्षण ग्राहक

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

परीक्षण ग्राहक के साथ आप कर सकते हैं कुछ चीजें हैं:

  • किसी URL पर GET और POST अनुरोधों का अनुकरण करें और प्रतिक्रिया का निरीक्षण करें - निम्न-स्तरीय HTTP (परिणाम हेडर और स्थिति कोड) से लेकर पृष्ठ सामग्री तक सब कुछ।
  • रीडायरेक्ट की श्रृंखला (यदि कोई हो) देखें और प्रत्येक चरण पर URL और स्थिति कोड देखें।
  • परीक्षण करें कि एक दिया गया अनुरोध किसी दिए गए Django टेम्पलेट द्वारा प्रदान किया गया है, जिसमें एक टेम्पलेट संदर्भ है जिसमें कुछ मान शामिल हैं।

ध्यान दें कि टेस्ट क्लाइंट का उद्देश्य Selenium या अन्य "इन-ब्राउज़र" फ्रेमवर्क के लिए प्रतिस्थापन नहीं है। Django के परीक्षण ग्राहक का एक अलग ध्यान केंद्रित है। संक्षेप में:

  • Django के परीक्षण क्लाइंट का उपयोग यह स्थापित करने के लिए करें कि सही टेम्प्लेट का प्रतिपादन किया जा रहा है और यह कि टेम्प्लेट को सही संदर्भ डेटा पास किया गया है।
  • HTML का परीक्षण करने के लिए Selenium जैसे ब्राउज़र फ्रेमवर्क का उपयोग करें और वेब पेजों का व्यवहार अर्थात् जावास्क्रिप्ट कार्यक्षमता। Django भी उन चौखटे के लिए विशेष समर्थन प्रदान करता है; अधिक विवरण के लिए LiveServerTestCase पर अनुभाग देखें।

एक व्यापक परीक्षण सूट को दोनों प्रकार के परीक्षण के संयोजन का उपयोग करना चाहिए।

अवलोकन और एक त्वरित उदाहरण

परीक्षण क्लाइंट का उपयोग करने के लिए, django.test.Client और वेब पेज पुनः प्राप्त करें:

>>> from django.test import Client
>>> c = Client()
>>> response = c.post('/login/', {'username': 'john', 'password': 'smith'})
>>> response.status_code
200
>>> response = c.get('/customer/details/')
>>> response.content
b'<!DOCTYPE html...'

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

परीक्षण क्लाइंट कैसे काम करता है, इसके बारे में कुछ महत्वपूर्ण बातों पर ध्यान दें:

  • परीक्षण क्लाइंट को चलने के लिए वेब सर्वर की आवश्यकता नहीं होती है। वास्तव में, यह बिना किसी वेब सर्वर के बिल्कुल ठीक चलेगा! ऐसा इसलिए है क्योंकि यह HTTP के ओवरहेड से बचा जाता है और सीधे Django के ढांचे से संबंधित है। यह इकाई परीक्षणों को शीघ्रता से चलाने में मदद करता है।
  • पृष्ठों को पुनर्प्राप्त करते समय, URL का पथ निर्दिष्ट करना याद रखें, न कि संपूर्ण डोमेन। उदाहरण के लिए, यह सही है:

    >>> c.get('/login/')
    

    यह गलत है:

    >>> c.get('https://www.example.com/login/')
    

    परीक्षण क्लाइंट उन वेब पृष्ठों को पुनः प्राप्त करने में सक्षम नहीं है जो आपके Django प्रोजेक्ट द्वारा संचालित नहीं हैं। यदि आपको अन्य वेब पेज पुनः प्राप्त करने की आवश्यकता है, तो पायथन मानक लाइब्रेरी मॉड्यूल जैसे कि urllib

  • URLs को हल करने के लिए, परीक्षण क्लाइंट आपके ROOT_URLCONF सेटिंग द्वारा URL -f जो भी इंगित करता है, का उपयोग करता है।
  • यद्यपि उपरोक्त उदाहरण पायथन इंटरएक्टिव दुभाषिया में काम करेगा, लेकिन कुछ परीक्षण क्लाइंट की कार्यक्षमता, विशेष रूप से टेम्पलेट से संबंधित कार्यक्षमता, केवल तभी उपलब्ध है जब परीक्षण चल रहे हों

    इसका कारण यह है कि Django के परीक्षण धावक एक निश्चित दृश्य द्वारा कौन सा टेम्पलेट लोड किया गया था, यह निर्धारित करने के लिए थोड़ा काला जादू करता है। यह काला जादू (अनिवार्य रूप से मेमोरी में Django के टेम्पलेट सिस्टम का एक पैच) केवल टेस्ट रनिंग के दौरान होता है।

  • डिफ़ॉल्ट रूप से, परीक्षण क्लाइंट आपकी साइट द्वारा किए गए किसी भी सीएसआरएफ चेक को अक्षम कर देगा।

    यदि, किसी कारण से, आप चाहते हैं कि परीक्षण ग्राहक CSRF जाँच करें, तो आप CSRF जाँच लागू करने वाले परीक्षण ग्राहक का एक उदाहरण बना सकते हैं। ऐसा करने के लिए, अपने ग्राहक का निर्माण करते समय enforce_csrf_checks तर्क में पास हों:

    >>> from django.test import Client
    >>> csrf_client = Client(enforce_csrf_checks=True)
    

अनुरोध करना

अनुरोध करने के लिए django.test.Client वर्ग का उपयोग करें।

class Client(enforce_csrf_checks=False, json_encoder=DjangoJSONEncoder, **defaults) [source]

इसके निर्माण के समय किसी तर्क की आवश्यकता नहीं है। हालाँकि, आप कुछ डिफ़ॉल्ट हेडर निर्दिष्ट करने के लिए कीवर्ड तर्क का उपयोग कर सकते हैं। उदाहरण के लिए, यह प्रत्येक अनुरोध में User-Agent HTTP हेडर भेजेगा:

>>> c = Client(HTTP_USER_AGENT='Mozilla/5.0')

get() , post() , आदि get() करने के get() पारित किए गए extra कीवर्ड के तर्कों के मानों में क्लास कंस्ट्रक्टर को दी गई चूक के बारे में पूर्वता है।

CSRF सुरक्षा (ऊपर देखें) का परीक्षण करने के लिए enforce_csrf_checks तर्क का उपयोग किया जा सकता है।

json_encoder तर्क JSON क्रमांकन के लिए एक कस्टम JSON एनकोडर सेट करने की अनुमति देता है जो post() में वर्णित है।

Django 2.1 में परिवर्तित:

json_encoder तर्क जोड़ा गया था।

एक बार आपके पास Client उदाहरण होने के बाद, आप निम्न विधियों में से किसी को भी कॉल कर सकते हैं:

get(path, data=None, follow=False, secure=False, **extra) [source]

उपलब्ध path पर एक GET अनुरोध बनाता है और एक Response ऑब्जेक्ट देता है, जो नीचे प्रलेखित है।

data डिक्शनरी में मुख्य-मूल्य जोड़े का उपयोग जीईटी डेटा पेलोड बनाने के लिए किया जाता है। उदाहरण के लिए:

>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7})

… के परिणाम के बराबर GET अनुरोध का मूल्यांकन होगा:

/customers/details/?name=fred&age=7

अनुरोध में भेजे जाने वाले शीर्ष लेखों को निर्दिष्ट करने के लिए extra खोजशब्द तर्क पैरामीटर का उपयोग किया जा सकता है। उदाहरण के लिए:

>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7},
...       HTTP_X_REQUESTED_WITH='XMLHttpRequest')

… HTTP शीर्ष लेख HTTP_X_REQUESTED_WITH को विवरण दृश्य में HTTP_X_REQUESTED_WITH , जो कोड पथों का परीक्षण करने का एक अच्छा तरीका है जो django.http.HttpRequest.is_ajax() विधि का उपयोग करता है।

सीजीआई विनिर्देश

**extra माध्यम से भेजे गए हेडर को CGI विनिर्देश का पालन करना चाहिए। उदाहरण के लिए, ब्राउज़र से सर्वर तक HTTP अनुरोध में भेजे गए एक अलग "होस्ट" हेडर का अनुकरण करके HTTP_HOST रूप में पारित किया जाना चाहिए।

यदि आपके पास URL-एन्कोडेड फ़ॉर्म में पहले से ही GET तर्क हैं, तो आप डेटा तर्क का उपयोग करने के बजाय उस एन्कोडिंग का उपयोग कर सकते हैं। उदाहरण के लिए, पिछले GET अनुरोध को भी निम्न प्रकार से प्रस्तुत किया जा सकता है:

>>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')

यदि आप एक एन्कोडेड GET डेटा और डेटा तर्क दोनों के साथ एक URL प्रदान करते हैं, तो डेटा तर्क पूर्वता लेगा।

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

यदि आपके पास एक URL /redirect_me/ जो पुनर्निर्देशित /next/ , कि पुनर्निर्देशित /final/ , यह वही है जो आप देखेंगे:

>>> response = c.get('/redirect_me/', follow=True)
>>> response.redirect_chain
[('http://testserver/next/', 302), ('http://testserver/final/', 302)]

यदि आप True secure सेट करते हैं तो क्लाइंट HTTPS अनुरोध का अनुकरण करेगा।

post(path, data=None, content_type=MULTIPART_CONTENT, follow=False, secure=False, **extra) [source]

उपलब्ध path पर एक POST अनुरोध बनाता है और एक Response ऑब्जेक्ट देता है, जो नीचे प्रलेखित है।

data डिक्शनरी में मुख्य-मूल्य जोड़े POST डेटा सबमिट करने के लिए उपयोग किए जाते हैं। उदाहरण के लिए:

>>> c = Client()
>>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})

... इस URL के लिए POST अनुरोध के मूल्यांकन में परिणाम होगा:

/login/

... इस POST डेटा के साथ:

name=fred&passwd=secret

यदि आप content_type को एप्लिकेशन / json के रूप में प्रदान करते हैं, तो json.dumps() साथ DjangoJSONEncoder json.dumps() का उपयोग करके एक data डिक्शनरी क्रमबद्ध की DjangoJSONEncoder । आप Client को json_encoder तर्क प्रदान करके एनकोडर को बदल सकते हैं। यह क्रमांकन put() , patch() , और delete() अनुरोधों के लिए भी होता है।

Django 2.1 में परिवर्तित:

ऊपर वर्णित JSON क्रमांकन जोड़ा गया था। पुराने संस्करणों में, आप एक ही चीज़ को प्राप्त करने के लिए post() करने के लिए post() पास करने से पहले data पर json.dumps() कॉल कर सकते हैं।

यदि आप कोई अन्य content_type (जैसे XML पेलोड के लिए पाठ / xml ) प्रदान करते हैं, तो data की सामग्री को POST अनुरोध में, content_type Content-Type हेडर में content_type का उपयोग करके भेजा जाता है।

यदि आप content_type लिए कोई मान प्रदान नहीं करते हैं, तो data में मानों को सामग्री प्रकार के मल्टीपार्ट / फ़ॉर्म-डेटा के साथ प्रेषित किया जाएगा। इस स्थिति में, data में की-वैल्यू जोड़े को एक मल्टीपार्ट संदेश के रूप में एन्कोड किया जाएगा और POST डेटा पेलोड बनाने के लिए उपयोग किया जाएगा।

किसी दिए गए कुंजी के लिए कई मान प्रस्तुत करने के लिए - उदाहरण के लिए, एक <select multiple> लिए चयन निर्दिष्ट करने के लिए - आवश्यक कुंजी के लिए सूची या टपल के रूप में मान प्रदान करें। उदाहरण के लिए, data का यह मान choices नाम वाले क्षेत्र के लिए तीन चयनित मान प्रस्तुत करेगा:

{'choices': ('a', 'b', 'd')}

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

>>> c = Client()
>>> with open('wishlist.doc') as fp:
...     c.post('/customers/wishes/', {'name': 'fred', 'attachment': fp})

(यहां नाम attachment प्रासंगिक नहीं है; आपके फ़ाइल-प्रोसेसिंग कोड को जो भी नाम दिया गया है, उसका उपयोग करें।)

आप किसी फ़ाइल- StringIO ऑब्जेक्ट (जैसे, StringIO या BytesIO ) को फ़ाइल हैंडल के रूप में भी प्रदान कर सकते हैं। यदि आप एक ImageField अपलोड कर रहे हैं, तो ऑब्जेक्ट को एक name विशेषता की आवश्यकता होती है जो validate_image_file_extension सत्यापनकर्ता को पास करता है। उदाहरण के लिए:

>>> from io import BytesIO
>>> img = BytesIO(b'mybinarydata')
>>> img.name = 'myimage.jpg'

ध्यान दें कि यदि आप एक से अधिक post() कॉल के लिए एक ही फाइल हैंडल का उपयोग करना चाहते हैं तो आपको पोस्ट के बीच फाइल पॉइंटर को मैन्युअल रूप से रीसेट करना होगा। ऐसा करने का सबसे आसान तरीका फ़ाइल को मैन्युअल रूप से बंद करना है क्योंकि इसे post() में प्रदान किया गया है, जैसा कि ऊपर दिखाया गया है।

आपको यह भी सुनिश्चित करना चाहिए कि फ़ाइल एक तरह से खोली गई है जो डेटा को पढ़ने की अनुमति देता है। यदि आपकी फ़ाइल में छवि के रूप में बाइनरी डेटा है, तो इसका मतलब है कि आपको फ़ाइल को rb (रीड बाइनरी) मोड में खोलने की आवश्यकता होगी।

extra तर्क get() लिए समान कार्य करता है।

यदि आपके द्वारा POST के साथ अनुरोध किए गए URL में एन्कोडेड पैरामीटर हैं, तो ये पैरामीटर request.GET डेटा में उपलब्ध कराए जाएंगे। उदाहरण के लिए, यदि आप अनुरोध करने वाले थे:

>>> c.post('/login/?visitor=true', {'name': 'fred', 'passwd': 'secret'})

... इस अनुरोध को संभालने वाला दृश्य उपयोगकर्ता नाम और पासवर्ड को पुनः प्राप्त करने के लिए request.POST से पूछताछ कर सकता है, और यदि उपयोगकर्ता एक आगंतुक था, तो यह निर्धारित करने के लिए अनुरोध पूछ सकते हैं।

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

यदि आप True secure सेट करते हैं तो क्लाइंट HTTPS अनुरोध का अनुकरण करेगा।

head(path, data=None, follow=False, secure=False, **extra) [source]

उपलब्ध path पर एक HEAD अनुरोध बनाता है और Response ऑब्जेक्ट देता है। यह विधि get() तरह ही काम करती है, जिसमें follow , secure और extra तर्क शामिल हैं, सिवाय इसके कि यह एक संदेश बॉडी को वापस नहीं करता है।

options(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source]

उपलब्ध path पर एक विकल्प का अनुरोध करता path और Response ऑब्जेक्ट देता है। रेस्टफुल इंटरफेस के परीक्षण के लिए उपयोगी।

जब data प्रदान किया जाता है, तो इसे अनुरोध निकाय के रूप में उपयोग किया जाता है, और Content-Type हेडर को content_type सेट किया जाता है।

follow , secure और extra तर्क get() लिए समान हैं।

put(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source]

उपलब्ध path पर एक PUT अनुरोध बनाता है और एक Response ऑब्जेक्ट देता है। रेस्टफुल इंटरफेस के परीक्षण के लिए उपयोगी।

जब data प्रदान किया जाता है, तो इसे अनुरोध निकाय के रूप में उपयोग किया जाता है, और Content-Type हेडर को content_type सेट किया जाता है।

follow , secure और extra तर्क get() लिए समान हैं।

patch(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source]

उपलब्ध path पर एक PATCH अनुरोध बनाता है और एक Response ऑब्जेक्ट देता है। रेस्टफुल इंटरफेस के परीक्षण के लिए उपयोगी।

follow , secure और extra तर्क get() लिए समान हैं।

delete(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source]

प्रदान किए गए path पर एक DELETE अनुरोध करता path और एक Response वस्तु देता है। रेस्टफुल इंटरफेस के परीक्षण के लिए उपयोगी।

जब data प्रदान किया जाता है, तो इसे अनुरोध निकाय के रूप में उपयोग किया जाता है, और Content-Type हेडर को content_type सेट किया जाता है।

follow , secure और extra तर्क get() लिए समान हैं।

trace(path, follow=False, secure=False, **extra) [source]

प्रदान path पर एक TRACE अनुरोध करता path और एक Response वस्तु देता है। नैदानिक ​​जांच अनुकरण के लिए उपयोगी है।

अन्य अनुरोध विधियों के विपरीत, RFC 7231 # अनुभाग-4.3.8 के अनुपालन के लिए data को एक कीवर्ड पैरामीटर के रूप में प्रदान नहीं किया गया है, जो बताता है कि TRACE अनुरोधों में एक निकाय नहीं होना चाहिए।

follow , secure और extra तर्क get() लिए समान हैं।

login(**credentials) [source]

यदि आपकी साइट Django के प्रमाणीकरण प्रणाली का उपयोग करती है और आप उपयोगकर्ताओं में लॉगिंग से निपटते हैं, तो आप साइट में प्रवेश करने वाले उपयोगकर्ता के प्रभाव को अनुकरण करने के login() परीक्षण क्लाइंट के login() विधि का उपयोग कर सकते हैं।

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

credentials तर्क का प्रारूप इस बात पर निर्भर करता है कि आप किस प्रमाणीकरण बैकएंड का उपयोग कर रहे हैं (जो आपके AUTHENTICATION_BACKENDS सेटिंग से कॉन्फ़िगर किया गया है)। यदि आप Django ( ModelBackend ) द्वारा प्रदान किए गए मानक प्रमाणीकरण बैकएंड का उपयोग कर रहे हैं, तो credentials उपयोगकर्ता के उपयोगकर्ता नाम और पासवर्ड, कीवर्ड तर्क के रूप में प्रदान credentials चाहिए:

>>> c = Client()
>>> c.login(username='fred', password='secret')

# Now you can access a view that's only available to logged-in users.

यदि आप एक अलग प्रमाणीकरण बैकएंड का उपयोग कर रहे हैं, तो इस पद्धति के लिए अलग-अलग क्रेडेंशियल की आवश्यकता हो सकती है। इसके लिए आपके बैकएंड की authenticate() विधि द्वारा जो भी प्रमाणिकता आवश्यक है।

login() रिटर्न True अगर यह क्रेडेंशियल स्वीकार किए जाते हैं और लॉगिन सफल था।

अंत में, आपको इस विधि का उपयोग करने से पहले उपयोगकर्ता खाते बनाने के लिए याद रखना होगा। जैसा कि हमने ऊपर बताया, परीक्षण धावक को एक परीक्षण डेटाबेस का उपयोग करके निष्पादित किया जाता है, जिसमें डिफ़ॉल्ट रूप से कोई उपयोगकर्ता नहीं होता है। परिणामस्वरूप, आपके उत्पादन साइट पर मान्य उपयोगकर्ता खाते परीक्षण स्थितियों में काम नहीं करेंगे। आपको उपयोगकर्ताओं को परीक्षण सूट के भाग के रूप में बनाने की आवश्यकता होगी - या तो मैन्युअल रूप से (Django मॉडल API का उपयोग करके) या परीक्षण स्थिरता के साथ। याद रखें कि यदि आप चाहते हैं कि आपके परीक्षण उपयोगकर्ता के पास पासवर्ड हो, तो आप पासवर्ड विशेषता को सीधे सेट करके उपयोगकर्ता के पासवर्ड को सेट नहीं कर सकते हैं - आपको सही ढंग से हैश किए गए पासवर्ड को संग्रहीत करने के लिए set_password() फ़ंक्शन का उपयोग करना होगा। वैकल्पिक रूप से, आप सही ढंग से हैशेड पासवर्ड के साथ एक नया उपयोगकर्ता बनाने के लिए create_user() सहायक विधि का उपयोग कर सकते हैं।

force_login(user, backend=None) [source]

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

login() विपरीत, यह विधि प्रमाणीकरण और सत्यापन चरणों को छोड़ देती है: निष्क्रिय उपयोगकर्ताओं ( is_active=False ) को लॉगिन करने की अनुमति है और उपयोगकर्ता की साख प्रदान करने की आवश्यकता नहीं है।

उपयोगकर्ता के पास backend तर्क (जो एक बिंदीदार पायथन पथ स्ट्रिंग होना चाहिए) के मान के लिए, या settings.AUTHENTICATION_BACKENDS[0] लिए settings.AUTHENTICATION_BACKENDS[0] किया गया है। यदि कोई मान प्रदान नहीं किया गया है। authenticate() फ़ंक्शन जिसे login() द्वारा कहा जाता है login() आम तौर पर उपयोगकर्ता को इस तरह एनोटेट करता है।

यह तरीका login() से अधिक तेज़ है क्योंकि महंगे पासवर्ड हैशिंग एल्गोरिदम को बायपास कर दिया जाता है। इसके अलावा, आप परीक्षण करते समय कमजोर हैशर का उपयोग करके login() को गति दे सकते हैं।

logout() [source]

यदि आपकी साइट Django के प्रमाणीकरण प्रणाली का उपयोग करती है , तो आपकी साइट से लॉगिंग करने वाले उपयोगकर्ता के प्रभाव को अनुकरण करने के लिए logout() विधि का उपयोग किया जा सकता है।

इस विधि को कॉल करने के बाद, परीक्षण क्लाइंट के पास सभी कुकी और सत्र डेटा डिफॉल्ट करने के लिए साफ़ हो जाएंगे। बाद के अनुरोध एक AnonymousUser से आते दिखाई देंगे।

परीक्षण प्रतिक्रियाएँ

get() और post() तरीके दोनों एक Response वस्तु लौटाते हैं। यह Response ऑब्जेक्ट HttpResponse ऑब्जेक्ट द्वारा Django के विचारों द्वारा लौटाए जाने के समान नहीं है; परीक्षण प्रतिक्रिया ऑब्जेक्ट में परीक्षण कोड को सत्यापित करने के लिए कुछ अतिरिक्त डेटा उपयोगी है।

विशेष रूप से, एक Response ऑब्जेक्ट में निम्नलिखित विशेषताएं होती हैं:

class Response
client

परीक्षण क्लाइंट जिसका उपयोग अनुरोध करने के लिए किया गया था जिसके परिणामस्वरूप प्रतिक्रिया हुई।

content

प्रतिक्रिया का शरीर, एक बाइटस्ट्रिंग के रूप में। यह अंतिम पृष्ठ सामग्री है जिसे दृश्य या किसी त्रुटि संदेश द्वारा प्रस्तुत किया गया है।

context

टेम्पलेट Context उदाहरण जिसका उपयोग प्रतिक्रिया सामग्री तैयार करने वाले टेम्पलेट को प्रस्तुत करने के लिए किया गया था।

यदि रेंडर किए गए पृष्ठ ने कई टेम्प्लेट का उपयोग किया है, तो context Context वस्तुओं की एक सूची होगी, जिस क्रम में उनका प्रतिपादन किया गया था।

रेंडरिंग के दौरान उपयोग किए जाने वाले टेम्प्लेट की संख्या के बावजूद, आप [] ऑपरेटर का उपयोग करके संदर्भ मान प्राप्त कर सकते हैं। उदाहरण के लिए, संदर्भ चर name का उपयोग करके पुनर्प्राप्त किया जा सकता है:

>>> response = client.get('/foo/')
>>> response.context['name']
'Arthur'

Django टेम्प्लेट का उपयोग नहीं कर रहा है?

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

json(**kwargs)

प्रतिक्रिया के शरीर, JSON के रूप में पार्स किया गया। अतिरिक्त कीवर्ड तर्क json.loads() को json.loads() जाते हैं। उदाहरण के लिए:

>>> response = client.get('/foo/')
>>> response.json()['name']
'Arthur'

यदि Content-Type हेडर "application/json" , तो प्रतिक्रिया को पार्स करने का प्रयास करते समय एक ValueError उठाया जाएगा।

request

अनुरोध डेटा जिसने प्रतिक्रिया को उत्तेजित किया।

wsgi_request

परीक्षण हैंडलर द्वारा उत्पन्न WSGIRequest उदाहरण जिसने प्रतिक्रिया उत्पन्न की।

status_code

एक पूर्णांक के रूप में प्रतिक्रिया की HTTP स्थिति। परिभाषित कोड की पूरी सूची के लिए, IANA स्थिति कोड रजिस्ट्री देखें

templates

अंतिम सामग्री को रेंडर करने के लिए उपयोग किए गए Template इंस्टेंस की एक सूची, जिस क्रम में वे प्रदान किए गए थे। सूची में प्रत्येक टेम्पलेट के लिए, टेम्पलेट का फ़ाइल नाम प्राप्त करने के लिए template.name का उपयोग करें, यदि टेम्पलेट किसी फ़ाइल से लोड किया गया था। (नाम एक स्ट्रिंग है जैसे कि 'admin/index.html' ।)

Django टेम्प्लेट का उपयोग नहीं कर रहा है?

यह विशेषता केवल DjangoTemplates बैकएंड का उपयोग करते समय आबादी है। यदि आप किसी अन्य टेम्पलेट इंजन का उपयोग कर रहे हैं, तो template_name एक उपयुक्त विकल्प हो सकता है यदि आपको केवल रेंडरिंग के लिए उपयोग किए जाने वाले टेम्पलेट का नाम चाहिए।

resolver_match

प्रतिक्रिया के लिए ResolverMatch का एक उदाहरण। आप func विशेषता का उपयोग कर सकते हैं, उदाहरण के लिए, प्रतिक्रिया को देखने वाले दृश्य को सत्यापित करने के लिए:

# my_view here is a function based view
self.assertEqual(response.resolver_match.func, my_view)

# class-based views need to be compared by name, as the functions
# generated by as_view() won't be equal
self.assertEqual(response.resolver_match.func.__name__, MyView.as_view().__name__)

यदि दिया गया URL नहीं मिला है, तो इस विशेषता को एक्सेस करने से Resolver404 अपवाद Resolver404 जाएगा।

आप HTTP हेडर में किसी भी सेटिंग्स के मूल्य को क्वेरी करने के लिए प्रतिक्रिया ऑब्जेक्ट पर डिक्शनरी सिंटैक्स का उपयोग कर सकते हैं। उदाहरण के लिए, आप response['Content-Type'] का उपयोग करके response['Content-Type'] का सामग्री प्रकार निर्धारित कर सकते हैं।

अपवाद

यदि आप किसी अपवाद को उठाते हुए परीक्षण क्लाइंट को इंगित करते हैं, तो वह अपवाद परीक्षण के मामले में दिखाई देगा। फिर आप अपवाद के लिए परीक्षण करने के लिए ब्लॉक या assertRaises() को try ... except एक मानक try ... except उपयोग कर सकते हैं।

परीक्षण ग्राहक को दिखाई नहीं देने वाले एकमात्र अपवाद Http404 , PermissionDenied , SystemExit , और SuspiciousOperation । Django इन अपवादों को आंतरिक रूप से पकड़ता है और उन्हें उचित HTTP प्रतिक्रिया कोड में परिवर्तित करता है। इन मामलों में, आप अपने परीक्षण में response.status_code जाँच कर सकते हैं।

लगातार रहने की अवस्था

परीक्षण क्लाइंट स्टेटफुल है। यदि कोई प्रतिक्रिया कुकी देता है, तो उस कुकी को परीक्षण क्लाइंट में संग्रहीत किया जाएगा और बाद के सभी get() और post() अनुरोधों के साथ भेजा जाएगा।

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

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

Client.cookies

एक पायथन SimpleCookie ऑब्जेक्ट, जिसमें सभी क्लाइंट कुकीज़ के वर्तमान मूल्य शामिल हैं। अधिक के लिए http.cookies मॉड्यूल के प्रलेखन देखें।

Client.session

एक शब्दकोश जैसी वस्तु जिसमें सत्र की जानकारी होती है। पूर्ण विवरण के लिए सत्र प्रलेखन देखें।

सत्र को संशोधित करने और फिर इसे सहेजने के लिए, इसे पहले एक चर में संग्रहित किया जाना चाहिए (क्योंकि इस संपत्ति के एक्सेस के बाद हर बार एक नया SessionStore बनाया जाता है):

def test_something(self):
    session = self.client.session
    session['somekey'] = 'test'
    session.save()

भाषा सेट करना

अंतर्राष्ट्रीयकरण और स्थानीयकरण का समर्थन करने वाले अनुप्रयोगों का परीक्षण करते समय, आप एक परीक्षण क्लाइंट अनुरोध के लिए भाषा सेट करना चाह सकते हैं। ऐसा करने की विधि इस बात पर निर्भर करती है कि LocaleMiddleware सक्षम है या नहीं।

यदि मिडलवेयर सक्षम है, तो भाषा LANGUAGE_COOKIE_NAME नाम और भाषा कोड के मान के साथ कुकी बनाकर सेट की जा सकती है:

from django.conf import settings

def test_language_using_cookie(self):
    self.client.cookies.load({settings.LANGUAGE_COOKIE_NAME: 'fr'})
    response = self.client.get('/')
    self.assertEqual(response.content, b"Bienvenue sur mon site.")

या अनुरोध में Accept-Language HTTP हेडर को शामिल करके:

def test_language_using_header(self):
    response = self.client.get('/', HTTP_ACCEPT_LANGUAGE='fr')
    self.assertEqual(response.content, b"Bienvenue sur mon site.")

अधिक जानकारी कैसे Django भाषा वरीयता को पता चलता है

यदि मिडलवेयर सक्षम नहीं है, तो सक्रिय भाषा translation.override() का उपयोग करके सेट की जा सकती है। translation.override() :

from django.utils import translation

def test_language_using_override(self):
    with translation.override('fr'):
        response = self.client.get('/')
    self.assertEqual(response.content, b"Bienvenue sur mon site.")

अधिक विवरण स्पष्ट रूप से सक्रिय भाषा को निर्धारित करने में हैं

उदाहरण

परीक्षण क्लाइंट का उपयोग करते हुए एक सरल इकाई परीक्षण निम्नलिखित है:

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def setUp(self):
        # Every test needs a client.
        self.client = Client()

    def test_details(self):
        # Issue a GET request.
        response = self.client.get('/customer/details/')

        # Check that the response is 200 OK.
        self.assertEqual(response.status_code, 200)

        # Check that the rendered context contains 5 customers.
        self.assertEqual(len(response.context['customers']), 5)

यह भी देखें

django.test.RequestFactory

बशर्ते परीक्षण केस कक्षाएं

सामान्य पायथन यूनिट परीक्षण कक्षाएं एक बेस क्लास को unittest.TestCase का विस्तार करती हैं। Django इस बेस क्लास के कुछ एक्सटेंशन प्रदान करता है:

Django इकाई परीक्षण श्रेणियों का पन्नुक्रम (TestCase उपवर्ग)

Django इकाई परीक्षण कक्षाओं के पदानुक्रम

किसी भी उपवर्ग में एक सामान्य unittest.TestCase परिवर्तित करना आसान है: अपने परीक्षण के आधार वर्ग को unittest.TestCase से उपवर्ग में बदलें। सभी मानक पायथन यूनिट परीक्षण कार्यक्षमता उपलब्ध होगी, और यह नीचे दिए गए प्रत्येक अनुभाग में वर्णित कुछ उपयोगी परिवर्धन के साथ संवर्धित किया जाएगा।

SimpleTestCase

class SimpleTestCase [source]

unittest.TestCase का एक उपवर्ग जो इस कार्यक्षमता को जोड़ता है:

यदि आपके परीक्षण कोई डेटाबेस प्रश्न बनाते हैं, तो उपक्लेसेस TransactionTestCase या TestCase उपयोग करें।

SimpleTestCase.allow_database_queries

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

चेतावनी

SimpleTestCase और उसके उपवर्ग (जैसे setUpClass() ,…) कुछ क्लास-वाइड इनिशियलाइज़ेशन (जैसे ओवरराइडिंग सेटिंग) करने के लिए setUpClass() और tearDownClass() पर भरोसा करते हैं। यदि आपको उन तरीकों को ओवरराइड करने की आवश्यकता है, तो super कार्यान्वयन को कॉल करना न भूलें:

class MyTestCase(TestCase):

    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        ...

    @classmethod
    def tearDownClass(cls):
        ...
        super().tearDownClass()

अगर setUpClass() के व्यवहार के लिए सुनिश्चित हो, यदि setUpClass() दौरान कोई अपवाद उठाया गया हो। यदि ऐसा होता है, तो न तो कक्षा में परीक्षण किए जाते हैं और न ही tearDownClass() चलाए जाते हैं। TestCase के मामले में, यह super() में बनाए गए लेनदेन को लीक कर देगा, जिसके परिणामस्वरूप कुछ प्लेटफार्मों पर एक विभाजन दोष सहित विभिन्न लक्षण दिखाई देते हैं (macOS पर रिपोर्ट किया गया)। यदि आप जानबूझकर कोई अपवाद उठाना चाहते हैं जैसे कि unittest.SkipTest in setUpClass() , तो इससे बचने के लिए super() कॉल करने से पहले इसे करना सुनिश्चित करें।

TransactionTestCase

class TransactionTestCase [source]

TransactionTestCase कुछ डेटाबेस-विशिष्ट सुविधाओं को जोड़ने के लिए SimpleTestCase से विरासत में मिला है:

Django का TestCase वर्ग TransactionTestCase का एक अधिक सामान्यतः उपयोग किया जाने वाला उपवर्ग है, जो प्रत्येक परीक्षण की शुरुआत में एक ज्ञात राज्य में डेटाबेस को रीसेट करने की प्रक्रिया को गति देने के लिए डेटाबेस लेनदेन सुविधाओं का उपयोग करता है। हालाँकि, इसका परिणाम यह है कि कुछ डेटाबेस व्यवहारों को एक Django TestCase वर्ग के भीतर परीक्षण नहीं किया जा सकता है। उदाहरण के लिए, आप यह परीक्षण नहीं कर सकते कि कोड का एक ब्लॉक किसी लेन-देन के भीतर चल रहा है, जैसा कि select_for_update() का उपयोग करते समय आवश्यक है। उन मामलों में, आपको TransactionTestCase उपयोग करना चाहिए।

TransactionTestCase और TestCase उस तरीके के अलावा समान हैं, जिसमें डेटाबेस ज्ञात अवस्था में रीसेट हो जाता है और कमिट और रोलबैक के प्रभावों का परीक्षण करने के लिए टेस्ट कोड की क्षमता होती है:

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

चेतावनी

TestCase उस डेटाबेस पर चल रहा है जो रोलबैक (जैसे MyISAM स्टोरेज इंजन के साथ MySQL) का समर्थन नहीं करता है, और TransactionTestCase सभी उदाहरण, परीक्षण डेटाबेस के सभी डेटा को हटाकर परीक्षण के अंत में वापस आ जाएंगे।

ऐप्स उनके डेटा को फिर से लोड नहीं देखेंगे ; यदि आपको इस कार्यक्षमता की आवश्यकता है (उदाहरण के लिए, तृतीय-पक्ष एप्लिकेशन को इसे सक्षम करना चाहिए) तो आप TestCase बॉडी के अंदर serialized_rollback = True सेट कर सकते हैं।

TestCase

class TestCase [source]

यह Django में परीक्षण लिखने के लिए उपयोग करने के लिए सबसे आम वर्ग है। यह TransactionTestCase (और विस्तार से SimpleTestCase ) से विरासत में मिला है। यदि आपका Django एप्लिकेशन डेटाबेस का उपयोग नहीं करता है, तो SimpleTestCase उपयोग करें।

कक्षा:

  • दो नेस्टेड atomic() ब्लॉकों के भीतर परीक्षणों को लपेटता है: पूरे वर्ग के लिए एक और प्रत्येक परीक्षण के लिए एक। इसलिए, यदि आप कुछ विशिष्ट डेटाबेस लेनदेन व्यवहार का परीक्षण करना चाहते हैं, तो TransactionTestCase उपयोग करें।
  • प्रत्येक परीक्षण के अंत में जाँच योग्य डेटाबेस की कमी की जाँच करता है।

यह एक अतिरिक्त विधि भी प्रदान करता है:

classmethod TestCase.setUpTestData() [source]

ऊपर वर्णित वर्ग-स्तरीय atomic ब्लॉक, क्लास TestCase स्तर पर प्रारंभिक डेटा के निर्माण की अनुमति देता है, एक बार पूरे TestCase । यह तकनीक setUp() का उपयोग करने की तुलना में तेज़ परीक्षणों की अनुमति देती है।

उदाहरण के लिए:

from django.test import TestCase

class MyTests(TestCase):
    @classmethod
    def setUpTestData(cls):
        # Set up data for the whole TestCase
        cls.foo = Foo.objects.create(bar="Test")
        ...

    def test1(self):
        # Some test using self.foo
        ...

    def test2(self):
        # Some other test using self.foo
        ...

ध्यान दें कि यदि परीक्षण डेटाबेस पर बिना लेन-देन समर्थन (उदाहरण के लिए, MySQL के साथ MySQL) के साथ setUpTestData() , तो setUpTestData() प्रत्येक परीक्षण से पहले बुलाया जाएगा, गति लाभों को नकार देगा।

अपने परीक्षण के तरीकों में setUpTestData() में बनाई गई किसी भी वस्तु को संशोधित करने के लिए सावधान रहें। वर्ग स्तर पर किए गए सेटअप कार्य से इन-मेमोरी ऑब्जेक्ट में संशोधन परीक्षण विधियों के बीच बने रहेंगे। यदि आपको उन्हें संशोधित करने की आवश्यकता है, तो आप उन्हें setUp() विधि में refresh_from_db()

LiveServerTestCase

class LiveServerTestCase [source]

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

लाइव सर्वर localhost पर सुनता है और पोर्ट 0 से बांधता है जो ऑपरेटिंग सिस्टम द्वारा सौंपे गए मुफ्त पोर्ट का उपयोग करता है। सर्वर के URL को परीक्षणों के दौरान self.live_server_url के साथ एक्सेस किया जा सकता है।

LiveServerTestCase का उपयोग करने का तरीका प्रदर्शित करने के लिए, आइए एक सरल सेलेनियम परीक्षण लिखें। सबसे पहले, आपको अपने पायथन पथ में सेलेनियम पैकेज स्थापित करने की आवश्यकता है:

$ pip install selenium
...\> pip install selenium

फिर, अपने ऐप के परीक्षण मॉड्यूल के लिए एक LiveServerTestCase myapp/tests.py परीक्षण जोड़ें (उदाहरण के लिए: myapp/tests.py )। इस उदाहरण के लिए, हम मान लेंगे कि आप staticfiles ऐप का उपयोग कर रहे हैं और चाहते हैं कि आपके परीक्षणों के निष्पादन के दौरान हमें जो समान फ़ाइलें प्राप्त हों, वे DEBUG=True साथ विकास के समय के समान हों, अर्थात बिना DEBUG=True उपयोग के उन्हें collectstatic । हम StaticLiveServerTestCase उपवर्ग का उपयोग करेंगे जो कि कार्यक्षमता प्रदान करता है। यदि आपको इसकी आवश्यकता नहीं है, तो इसे django.test.LiveServerTestCase बदलें।

इस परीक्षा के लिए कोड निम्नानुसार हो सकता है:

from django.contrib.staticfiles.testing import StaticLiveServerTestCase
from selenium.webdriver.firefox.webdriver import WebDriver

class MySeleniumTests(StaticLiveServerTestCase):
    fixtures = ['user-data.json']

    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        cls.selenium = WebDriver()
        cls.selenium.implicitly_wait(10)

    @classmethod
    def tearDownClass(cls):
        cls.selenium.quit()
        super().tearDownClass()

    def test_login(self):
        self.selenium.get('%s%s' % (self.live_server_url, '/login/'))
        username_input = self.selenium.find_element_by_name("username")
        username_input.send_keys('myuser')
        password_input = self.selenium.find_element_by_name("password")
        password_input.send_keys('secret')
        self.selenium.find_element_by_xpath('//input[@value="Log in"]').click()

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

$ ./manage.py test myapp.tests.MySeleniumTests.test_login
...\> manage.py test myapp.tests.MySeleniumTests.test_login

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

ध्यान दें

परीक्षणों को चलाने के लिए इन-मेमोरी SQLite डेटाबेस का उपयोग करते समय, समान डेटाबेस कनेक्शन को दो थ्रेड्स द्वारा समानांतर में साझा किया जाएगा: थ्रेड जिसमें लाइव सर्वर चलाया जाता है और वह थ्रेड जिसमें परीक्षण केस चलता है। दो थ्रेड्स द्वारा इस साझा कनेक्शन के माध्यम से एक साथ डेटाबेस प्रश्नों को रोकने के लिए महत्वपूर्ण है, क्योंकि कभी-कभी यादृच्छिक रूप से परीक्षण विफल हो सकते हैं। इसलिए आपको यह सुनिश्चित करने की आवश्यकता है कि दो धागे एक ही समय में डेटाबेस तक नहीं पहुंचते हैं। विशेष रूप से, इसका मतलब है कि कुछ मामलों में (उदाहरण के लिए, बस एक लिंक पर क्लिक करने के बाद या एक फॉर्म सबमिट करने के बाद), आपको यह जांचने की आवश्यकता हो सकती है कि सेलेनियम द्वारा एक प्रतिक्रिया प्राप्त हुई है और अगले पृष्ठ को आगे के परीक्षण के निष्पादन से पहले लोड किया गया है। उदाहरण के लिए, सेलेनियम को तब तक प्रतीक्षा करें जब तक कि <body> HTML टैग प्रतिक्रिया में न मिल जाए (सेलेनियम> 2.13 की आवश्यकता है):

def test_login(self):
    from selenium.webdriver.support.wait import WebDriverWait
    timeout = 2
    ...
    self.selenium.find_element_by_xpath('//input[@value="Log in"]').click()
    # Wait until the response is received
    WebDriverWait(self.selenium, timeout).until(
        lambda driver: driver.find_element_by_tag_name('body'))

यहाँ मुश्किल बात यह है कि वास्तव में "पेज लोड" जैसी कोई चीज नहीं है, विशेष रूप से आधुनिक वेब ऐप में जो कि सर्वर को प्रारंभिक दस्तावेज बनाने के बाद गतिशील रूप से HTML उत्पन्न करता है। तो, केवल <body> प्रतिक्रिया की उपस्थिति के लिए जाँच करना जरूरी नहीं कि सभी उपयोग के मामलों के लिए उपयुक्त हो। कृपया अधिक जानकारी के लिए सेलेनियम एफएक्यू और सेलेनियम प्रलेखन देखें।

परीक्षण के मामले सुविधाएँ

डिफ़ॉल्ट परीक्षण ग्राहक

SimpleTestCase.client

एक django.test.*TestCase उदाहरण में प्रत्येक परीक्षण मामले में एक Django परीक्षण क्लाइंट की आवृत्ति तक पहुँच होती है। इस ग्राहक के रूप में पहुँचा जा सकता है self.client । यह ग्राहक प्रत्येक परीक्षण के लिए बनाया गया है, इसलिए आपको एक परीक्षण से दूसरे परीक्षण में ले जाने की स्थिति (जैसे कि कुकीज़) के बारे में चिंता करने की आवश्यकता नहीं है।

इसका अर्थ है, Client प्रत्येक परीक्षा में तत्काल के बजाय :

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def test_details(self):
        client = Client()
        response = client.get('/customer/details/')
        self.assertEqual(response.status_code, 200)

    def test_index(self):
        client = Client()
        response = client.get('/customer/index/')
        self.assertEqual(response.status_code, 200)

... आप बस का उल्लेख कर सकते हैं self.client , जैसे:

from django.test import TestCase

class SimpleTest(TestCase):
    def test_details(self):
        response = self.client.get('/customer/details/')
        self.assertEqual(response.status_code, 200)

    def test_index(self):
        response = self.client.get('/customer/index/')
        self.assertEqual(response.status_code, 200)

परीक्षण ग्राहक को अनुकूलित करना

SimpleTestCase.client_class

यदि आप एक अलग Client वर्ग (उदाहरण के लिए, अनुकूलित व्यवहार के साथ एक उपवर्ग) का उपयोग करना चाहते हैं, तो client_class वर्ग विशेषता का उपयोग करें :

from django.test import Client, TestCase

class MyTestClient(Client):
    # Specialized methods for your environment
    ...

class MyTest(TestCase):
    client_class = MyTestClient

    def test_my_stuff(self):
        # Here self.client is an instance of MyTestClient...
        call_some_test_code()

स्थिरता लोड हो रहा है

TransactionTestCase.fixtures

यदि डेटाबेस में कोई डेटा नहीं है, तो डेटाबेस-समर्थित वेबसाइट के लिए परीक्षण का मामला ज्यादा उपयोग नहीं होता है। परीक्षण अधिक पठनीय हैं और यह ORM का उपयोग करके ऑब्जेक्ट बनाने के लिए अधिक अनुरक्षण योग्य है, उदाहरण के लिए TestCase.setUpTestData() , हालांकि, आप जुड़नार का उपयोग भी कर सकते हैं।

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

फ़िक्शन बनाने का सबसे सीधा तरीका manage.py dumpdata कमांड का उपयोग करना है । यह मानता है कि आपके डेटाबेस में पहले से ही कुछ डेटा है। dumpdata documentation अधिक जानकारी के लिए देखें।

एक बार जब आपने एक स्थिरता बना ली है और इसे अपनी एक fixtures निर्देशिका में रखा है INSTALLED_APPS , तो आप इसे अपने यूनिट परीक्षणों में fixtures अपने TestCase उपवर्ग पर एक वर्ग विशेषता निर्दिष्ट करके उपयोग कर सकते हैं :

from django.test import TestCase
from myapp.models import Animal

class AnimalTestCase(TestCase):
    fixtures = ['mammals.json', 'birds']

    def setUp(self):
        # Test definitions as before.
        call_setup_methods()

    def test_fluffy_animals(self):
        # A test that uses the fixtures.
        call_some_test_code()

यहाँ विशेष रूप से क्या होगा:

  • प्रत्येक परीक्षण के प्रारंभ में, setUp() चलाने से पहले , Django डेटाबेस को फ्लश कर देगा, डेटाबेस को उस स्थिति में लौटा देगा migrate जिसे सीधे बुलाया गया था।
  • फिर, सभी नामित जुड़नार स्थापित किए जाते हैं। इस उदाहरण में, Django किसी भी JSON स्थिरता को स्थापित करेगा mammals , जिसका नाम किसी भी स्थिरता के नाम पर होगा birds loaddata जुड़नार को परिभाषित करने और स्थापित करने के बारे में अधिक जानकारी के लिए दस्तावेज देखें ।

प्रदर्शन कारणों TestCase से TestCase.setUpTestData() , प्रत्येक परीक्षा से पहले के बजाय , पूरे परीक्षण वर्ग के लिए एक बार फिक्स्चर लोड करता है, और यह परीक्षण से पहले डेटाबेस को साफ करने के लिए लेनदेन का उपयोग करता है। किसी भी मामले में, आप निश्चित हो सकते हैं कि एक परीक्षण का परिणाम दूसरे परीक्षण या परीक्षण निष्पादन के आदेश से प्रभावित नहीं होगा।

डिफ़ॉल्ट रूप से, जुड़नार केवल default डेटाबेस में लोड होते हैं । यदि आप कई डेटाबेस और सेट का उपयोग कर रहे हैं multi_db=True , तो जुड़नार सभी डेटाबेस में लोड किए जाएंगे।

URLconf कॉन्फ़िगरेशन

यदि आपका आवेदन विचार प्रदान करता है, तो आप उन परीक्षणों को शामिल करना चाह सकते हैं जो परीक्षण ग्राहक का उपयोग उन विचारों को करने के लिए करते हैं। हालाँकि, एक अंतिम उपयोगकर्ता आपके एप्लिकेशन में अपने चयन के किसी भी URL पर विचारों को तैनात करने के लिए स्वतंत्र है। इसका अर्थ है कि आपके परीक्षण इस तथ्य पर भरोसा नहीं कर सकते हैं कि आपके विचार किसी विशेष URL पर उपलब्ध होंगे। @override_settings(ROOT_URLCONF=...) URLconf कॉन्फ़िगरेशन के लिए अपने परीक्षण वर्ग या परीक्षण विधि को सजाने के लिए।

मल्टी-डेटाबेस समर्थन

TransactionTestCase.multi_db

Django प्रत्येक डेटाबेस के अनुरूप एक परीक्षण डेटाबेस सेट करता है जिसे DATABASES आपकी सेटिंग फ़ाइल में परिभाषा में परिभाषित किया गया है । हालाँकि, Django TestCase को चलाने में लगने वाले समय का एक बड़ा हिस्सा उस कॉल के लिए लिया जाता है flush जो यह सुनिश्चित करता है कि आपके पास प्रत्येक टेस्ट रन की शुरुआत में एक साफ़ डेटाबेस हो। यदि आपके पास कई डेटाबेस हैं, तो कई फ़्लश की आवश्यकता होती है (प्रत्येक डेटाबेस के लिए एक), जो एक समय लेने वाली गतिविधि हो सकती है - खासकर अगर आपके परीक्षणों को मल्टी-डेटाबेस गतिविधि का परीक्षण करने की आवश्यकता नहीं है।

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

उदाहरण के लिए:

class TestMyViews(TestCase):
    multi_db = True

    def test_index_page_view(self):
        call_some_test_code()

यह परीक्षण मामला चलने से पहले सभी परीक्षण डेटाबेस को फ्लश करेगा test_index_page_view

multi_db झंडा भी है जिसमें डेटाबेस को प्रभावित करता है fixtures लोड किए गए हैं। डिफ़ॉल्ट रूप से (जब multi_db=False ), जुड़नार केवल default डेटाबेस में लोड किए जाते हैं । यदि multi_db=True , जुड़नार सभी डेटाबेस में लोड किए जाते हैं।

ओवरराइडिंग सेटिंग्स

चेतावनी

परीक्षणों में सेटिंग्स के मूल्य को अस्थायी रूप से बदलने के लिए नीचे दिए गए कार्यों का उपयोग करें। django.conf.settings सीधे जोड़ तोड़ मत करो क्योंकि Django ऐसे जोड़तोड़ के बाद मूल मूल्यों को बहाल नहीं करेगा।

SimpleTestCase.settings() [source]

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

from django.test import TestCase

class LoginTestCase(TestCase):

    def test_login(self):

        # First check for the default behavior
        response = self.client.get('/sekrit/')
        self.assertRedirects(response, '/accounts/login/?next=/sekrit/')

        # Then override the LOGIN_URL setting
        with self.settings(LOGIN_URL='/other/login/'):
            response = self.client.get('/sekrit/')
            self.assertRedirects(response, '/other/login/?next=/sekrit/')

यह उदाहरण ब्लॉक LOGIN_URL में कोड के लिए सेटिंग को ओवरराइड करेगा with और इसके मूल्य को बाद की स्थिति में रीसेट करेगा।

SimpleTestCase.modify_settings() [source]

यह उन सेटिंग को फिर से परिभाषित करने में अक्षम साबित हो सकता है जिनमें मूल्यों की सूची होती है। व्यवहार में, मूल्यों को जोड़ना या निकालना अक्सर पर्याप्त होता है। modify_settings() संदर्भ प्रबंधक यह आसान बनाता है:

from django.test import TestCase

class MiddlewareTestCase(TestCase):

    def test_cache_middleware(self):
        with self.modify_settings(MIDDLEWARE={
            'append': 'django.middleware.cache.FetchFromCacheMiddleware',
            'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
            'remove': [
                'django.contrib.sessions.middleware.SessionMiddleware',
                'django.contrib.auth.middleware.AuthenticationMiddleware',
                'django.contrib.messages.middleware.MessageMiddleware',
            ],
        }):
            response = self.client.get('/')
            # ...

प्रत्येक क्रिया के लिए, आप या तो मानों की सूची या एक स्ट्रिंग की आपूर्ति कर सकते हैं। जब मूल्य सूची में पहले से मौजूद है, append और prepend इसका कोई प्रभाव नहीं है; न तो remove तब होता है जब मूल्य मौजूद नहीं होता है।

override_settings() [source]

यदि आप परीक्षण विधि के लिए सेटिंग को ओवरराइड करना चाहते हैं, तो Django override_settings() डेकोरेटर ( PEP 318 देखें ) प्रदान करता है । यह इस तरह प्रयोग किया जाता है:

from django.test import TestCase, override_settings

class LoginTestCase(TestCase):

    @override_settings(LOGIN_URL='/other/login/')
    def test_login(self):
        response = self.client.get('/sekrit/')
        self.assertRedirects(response, '/other/login/?next=/sekrit/')

डेकोरेटर को TestCase कक्षाओं में भी लगाया जा सकता है :

from django.test import TestCase, override_settings

@override_settings(LOGIN_URL='/other/login/')
class LoginTestCase(TestCase):

    def test_login(self):
        response = self.client.get('/sekrit/')
        self.assertRedirects(response, '/other/login/?next=/sekrit/')
modify_settings() [source]

इसी तरह, Django modify_settings() सज्जाकार प्रदान करता है :

from django.test import TestCase, modify_settings

class MiddlewareTestCase(TestCase):

    @modify_settings(MIDDLEWARE={
        'append': 'django.middleware.cache.FetchFromCacheMiddleware',
        'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
    })
    def test_cache_middleware(self):
        response = self.client.get('/')
        # ...

डेकोरेटर को टेस्ट केस कक्षाओं में भी लगाया जा सकता है:

from django.test import TestCase, modify_settings

@modify_settings(MIDDLEWARE={
    'append': 'django.middleware.cache.FetchFromCacheMiddleware',
    'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
})
class MiddlewareTestCase(TestCase):

    def test_cache_middleware(self):
        response = self.client.get('/')
        # ...

ध्यान दें

जब एक कक्षा दी जाती है, तो ये सज्जाकार सीधे कक्षा को संशोधित करते हैं और इसे वापस लौटाते हैं; वे नहीं बनाते हैं और इसकी एक संशोधित प्रति लौटाते हैं। तो अगर आप की तुलना में एक अलग नाम के लिए वापसी मान देना उपरोक्त उदाहरण tweak करने की कोशिश LoginTestCase या MiddlewareTestCase , आप को खोजने के लिए है कि मूल परीक्षण का मामला कक्षाएं अभी भी समान रूप से डेकोरेटर से प्रभावित हैं हैरान हो सकता है। किसी दिए गए वर्ग के लिए, modify_settings() हमेशा के बाद लागू किया जाता है override_settings()

चेतावनी

सेटिंग्स फ़ाइल में कुछ सेटिंग्स हैं जो केवल Django के इंटर्नल के प्रारंभ के दौरान परामर्श की जाती हैं। यदि आप उन्हें बदलते हैं override_settings , तो django.conf.settings मॉड्यूल के माध्यम से इसे एक्सेस करने पर सेटिंग बदल जाती है , हालाँकि, Django के इंटर्नल इसे अलग तरीके से एक्सेस करते हैं। प्रभावी रूप से, इन सेटिंग्स का उपयोग करना override_settings() या उनके modify_settings() साथ करना संभव नहीं है।

हम DATABASES सेटिंग को बदलने की अनुशंसा नहीं करते हैं । CACHES सेटिंग को बदलना संभव है, लेकिन अगर आप इंटर्नल का उपयोग कर रहे हैं तो थोड़ा मुश्किल है, जैसे कि कैशिंग का उपयोग करना django.contrib.sessions । उदाहरण के लिए, आपको एक परीक्षण में सत्र बैकएंड को फिर से संगठित करना होगा जो कैश्ड सत्र और ओवरराइड का उपयोग करता है CACHES

अंत में, अपनी सेटिंग को मॉड्यूल-स्तरीय स्थिरांक के रूप में बदलने से बचें override_settings() क्योंकि वे ऐसे मूल्यों पर काम नहीं करेंगे, क्योंकि वे केवल पहली बार मूल्यांकन किए जाते हैं कि मॉड्यूल आयात किया गया है।

सेटिंग की ओवरराइड होने पर इसे हटाकर आप सेटिंग की अनुपस्थिति का अनुकरण भी कर सकते हैं, जैसे:

@override_settings()
def test_something(self):
    del settings.LOGIN_URL
    ...

सेटिंग को ओवरराइड करते समय, उन मामलों को संभालना सुनिश्चित करें जिनमें आपके ऐप का कोड कैश या इसी तरह की सुविधा का उपयोग करता है जो सेटिंग को बदलने पर भी स्थिति को बनाए रखता है। Django django.test.signals.setting_changed सिग्नल देता है जो आपको सेटिंग्स को बदलने पर कॉलबैक को पंजीकृत करने और अन्यथा स्थिति को रीसेट करने की सुविधा देता है।

Django स्वयं इस संकेत का उपयोग विभिन्न डेटा को रीसेट करने के लिए करता है:

ओवररेटेड सेटिंग्स डेटा रीसेट
USE_TZ, TIME_ZONE डेटाबेस समयक्षेत्र
खाके टेम्पलेट इंजन
SERIALIZATION_MODULES सीरियल के कैश
LOCALE_PATHS, LANGUAGE_CODE डिफ़ॉल्ट अनुवाद और लोड किए गए अनुवाद
MEDIA_ROOT, DEFAULT_FILE_STORAGE डिफ़ॉल्ट फ़ाइल संग्रहण

परीक्षण आउटबॉक्स खाली करना

यदि आप Django के किसी भी कस्टम TestCase वर्ग का उपयोग करते हैं, तो परीक्षण धावक प्रत्येक परीक्षण मामले की शुरुआत में परीक्षण ईमेल आउटबॉक्स की सामग्री को साफ़ कर देगा।

परीक्षणों के दौरान ईमेल सेवाओं पर अधिक विवरण के लिए, नीचे दी गई ईमेल सेवाएँ देखें।

इस प्रकार के दावे

अजगर की सामान्य रूप में unittest.TestCase वर्ग जैसे दावे तरीकों को लागू करता है assertTrue() और assertEqual() , Django के कस्टम TestCase वर्ग कस्टम अभिकथन तरीकों कि परीक्षण वेब अनुप्रयोगों के लिए उपयोगी होते हैं के एक नंबर प्रदान करता है:

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

SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable, *args, **kwargs) [source]
SimpleTestCase.assertRaisesMessage(expected_exception, expected_message)

की है कि निष्पादन का दावा callable उठाता expected_exception और कहा कि expected_message अपवाद के संदेश में पाया जाता है। किसी अन्य परिणाम को विफलता के रूप में सूचित किया जाता है। यह unittest.TestCase.assertRaisesRegex() अंतर का एक सरल संस्करण expected_message है जिसे एक नियमित अभिव्यक्ति के रूप में नहीं माना जाता है।

यदि केवल expected_exception और expected_message पैरामीटर दिए गए हैं, तो एक संदर्भ प्रबंधक देता है ताकि परीक्षण किए जा रहे कोड को फ़ंक्शन के बजाय इनलाइन लिखा जा सके:

with self.assertRaisesMessage(ValueError, 'invalid literal for int()'):
    int('a')
SimpleTestCase.assertWarnsMessage(expected_warning, expected_message, callable, *args, **kwargs) [source]
SimpleTestCase.assertWarnsMessage(expected_warning, expected_message)
Django 2.1 में नया:

SimpleTestCase.assertRaisesMessage() के assertWarnsRegex() बजाय के लिए अनुरूप unittest.TestCase.assertRaisesRegex()

SimpleTestCase.assertFieldOutput(fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value='') [source]

यह कहता है कि एक फार्म फील्ड विभिन्न इनपुट्स के साथ सही व्यवहार करता है।

पैरामीटर:
  • फ़ील्डक्लास - परीक्षण किए जाने वाले क्षेत्र का वर्ग।
  • मान्य - एक शब्दकोश मानचित्रण उनके अपेक्षित साफ किए गए मूल्यों के लिए मान्य इनपुट।
  • अमान्य - एक शब्दकोश एक या अधिक उठाए गए त्रुटि संदेशों के लिए अमान्य इनपुट मैपिंग।
  • field_args - फ़ील्ड को तत्काल करने के लिए पारित किया गया args।
  • field_kwargs - kwargs मैदान को पलटने के लिए पारित किया।
  • vac_value - इनपुट के लिए अपेक्षित स्वच्छ आउटपुट empty_values

उदाहरण के लिए, निम्न कोड परीक्षण EmailField करता है [email protected] जो एक मान्य ईमेल पते के रूप में स्वीकार करता है , लेकिन aaa एक उचित त्रुटि संदेश के साथ अस्वीकार करता है :

self.assertFieldOutput(EmailField, {'[email protected]': '[email protected]'}, {'aaa': ['Enter a valid email address.']})
SimpleTestCase.assertFormError(response, form, field, errors, msg_prefix='') [source]

यह बताता है कि प्रपत्र पर प्रदान किए जाने पर प्रपत्र पर कोई फ़ील्ड त्रुटियों की सूची प्रदान करता है।

form वह नाम है जिसका Form उदाहरण टेम्पलेट संदर्भ में दिया गया था।

field जाँच करने के लिए प्रपत्र पर फ़ील्ड का नाम है। यदि field मूल्य का None , गैर-क्षेत्र त्रुटियों (त्रुटियों के माध्यम से आप तक पहुँच सकते हैं form.non_field_errors() ) की जाँच की जाएगी।

errors एक त्रुटि स्ट्रिंग, या त्रुटि स्ट्रिंग की एक सूची है, जो फॉर्म सत्यापन के परिणामस्वरूप अपेक्षित हैं।

SimpleTestCase.assertFormsetError(response, formset, form_index, field, errors, msg_prefix='') [source]

दावा है कि formset त्रुटियों के प्रदान की गई सूची जब गाया उठाती है।

formset वह नाम है जिसका Formset उदाहरण टेम्पलेट संदर्भ में दिया गया था।

form_index फार्म की संख्या के भीतर है Formset । यदि form_index मूल्य का None , गैर-प्रपत्र त्रुटियों (त्रुटियों के माध्यम से आप तक पहुँच सकते हैं formset.non_form_errors() ) की जाँच की जाएगी।

field जाँच करने के लिए प्रपत्र पर फ़ील्ड का नाम है। यदि field मूल्य का None , गैर-क्षेत्र त्रुटियों (त्रुटियों के माध्यम से आप तक पहुँच सकते हैं form.non_field_errors() ) की जाँच की जाएगी।

errors एक त्रुटि स्ट्रिंग, या त्रुटि स्ट्रिंग की एक सूची है, जो फॉर्म सत्यापन के परिणामस्वरूप अपेक्षित हैं।

SimpleTestCase.assertContains(response, text, count=None, status_code=200, msg_prefix='', html=False) [source]

यह दावा करता है कि एक Response उदाहरण दिए गए status_code और text प्रतिक्रिया की सामग्री में प्रकट होता है। यदि count प्रदान किया गया है, तो प्रतिक्रिया में text बिल्कुल count समय होना चाहिए ।

HTML के रूप में संभालने के html लिए सेट करें । प्रतिक्रिया सामग्री के साथ तुलना चरित्र-दर-वर्ण समानता के बजाय HTML शब्दार्थ पर आधारित होगी। ज्यादातर मामलों में व्हाट्सएप को नजरअंदाज किया जाता है, विशेषता क्रम महत्वपूर्ण नहीं है। अधिक जानकारी के लिए देखें। True text assertHTMLEqual()

SimpleTestCase.assertNotContains(response, text, status_code=200, msg_prefix='', html=False) [source]

का दावा है कि एक Response उदाहरण उत्पादित दिया status_code और कहा कि text है नहीं प्रतिक्रिया की सामग्री में दिखाई देते हैं।

HTML के रूप में संभालने के html लिए सेट करें । प्रतिक्रिया सामग्री के साथ तुलना चरित्र-दर-वर्ण समानता के बजाय HTML शब्दार्थ पर आधारित होगी। ज्यादातर मामलों में व्हाट्सएप को नजरअंदाज किया जाता है, विशेषता क्रम महत्वपूर्ण नहीं है। अधिक जानकारी के लिए देखें। True text assertHTMLEqual()

SimpleTestCase.assertTemplateUsed(response, template_name, msg_prefix='', count=None) [source]

प्रतिक्रिया देने के लिए दिए गए नाम के टेम्पलेट का उपयोग किया गया है।

नाम एक स्ट्रिंग है जैसे 'admin/index.html'

गिनती तर्क एक पूर्णांक है जो यह दर्शाता है कि टेम्पलेट को कितनी बार प्रस्तुत किया जाना चाहिए। डिफ़ॉल्ट है None , जिसका अर्थ है कि टेम्पलेट को एक या अधिक बार प्रस्तुत किया जाना चाहिए।

आप इसे संदर्भ प्रबंधक के रूप में उपयोग कर सकते हैं, जैसे:

with self.assertTemplateUsed('index.html'):
    render_to_string('index.html')
with self.assertTemplateUsed(template_name='index.html'):
    render_to_string('index.html')
SimpleTestCase.assertTemplateNotUsed(response, template_name, msg_prefix='') [source]

प्रतिक्रिया देने के लिए दिए गए नाम के टेम्पलेट का उपयोग नहीं किया गया है।

आप इसे संदर्भ प्रबंधक के रूप में उसी तरह उपयोग कर सकते हैं assertTemplateUsed()

SimpleTestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200, msg_prefix='', fetch_redirect_response=True) [source]

यह दावा करता है कि प्रतिक्रिया ने status_code पुनर्निर्देशित स्थिति लौटा दी , expected_url (किसी भी GET डेटा सहित ) पर पुनर्निर्देशित किया गया , और अंतिम पृष्ठ के साथ प्राप्त किया गया target_status_code

यदि आपके अनुरोध ने follow तर्क का उपयोग किया है, expected_url और target_status_code रीडायरेक्ट श्रृंखला के अंतिम बिंदु के लिए url और स्थिति कोड होगा।

यदि fetch_redirect_response है False , तो अंतिम पृष्ठ लोड नहीं किया जाएगा। चूंकि टेस्ट क्लाइंट बाहरी URL नहीं ला सकता है, यह विशेष रूप से उपयोगी है यदि expected_url आपके Django ऐप का हिस्सा नहीं है।

दो URL के बीच तुलना करते समय योजना को सही ढंग से नियंत्रित किया जाता है। यदि उस स्थान पर निर्दिष्ट कोई योजना नहीं है जहाँ हम उस पर पुनः निर्देशित होते हैं, तो मूल अनुरोध की योजना का उपयोग किया जाता है। यदि मौजूद है, तो इस योजना का expected_url उपयोग तुलना करने के लिए किया जाता है।

SimpleTestCase.assertHTMLEqual(html1, html2, msg=None) [source]

जोर देता है कि तार html1 और html2 समान हैं। तुलना HTML शब्दार्थ पर आधारित है। तुलना निम्नलिखित बातों को ध्यान में रखती है:

  • HTML टैग से पहले और बाद में व्हाट्सएप को नजरअंदाज कर दिया जाता है।
  • सभी प्रकार के व्हाट्सएप को समकक्ष माना जाता है।
  • सभी खुले टैगों को अंतर्निहित रूप से बंद कर दिया जाता है, जैसे कि जब कोई आसपास का टैग बंद हो जाता है या HTML दस्तावेज़ समाप्त हो जाता है।
  • खाली टैग उनके स्व-समापन संस्करण के बराबर हैं।
  • एक HTML तत्व की विशेषताओं का क्रम महत्वपूर्ण नहीं है।
  • एक तर्क के बिना विशेषताएँ नाम और मूल्य (उदाहरण देखें) के बराबर विशेषताओं के बराबर हैं।

निम्नलिखित उदाहरण वैध परीक्षण हैं और कोई भी वृद्धि नहीं करते हैं AssertionError :

self.assertHTMLEqual(
    '<p>Hello <b>world!</p>',
    '''<p>
        Hello   <b>world! </b>
    </p>'''
)
self.assertHTMLEqual(
    '<input type="checkbox" checked="checked" id="id_accept_terms" />',
    '<input id="id_accept_terms" type="checkbox" checked>'
)

html1 और html2 मान्य HTML होना चाहिए। एक AssertionError अगर उनमें से एक पार्स नहीं किया जा सकता बढ़ा दी जाएगी।

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None) [source]

जोर देता है कि तार html1 और समान नहीं html2 हैं । तुलना HTML शब्दार्थ पर आधारित है। विवरण के लिए देखें। assertHTMLEqual()

html1 और html2 मान्य HTML होना चाहिए। एक AssertionError अगर उनमें से एक पार्स नहीं किया जा सकता बढ़ा दी जाएगी।

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None) [source]

जोर देता है कि तार xml1 और xml2 समान हैं। तुलना एक्सएमएल शब्दार्थ पर आधारित है। इसी तरह assertHTMLEqual() , तुलना पार्स सामग्री पर की जाती है, इसलिए केवल सिमेंटिक अंतर को माना जाता है, सिंटैक्स मतभेद नहीं। जब किसी भी पैरामीटर में अमान्य XML पारित हो जाता AssertionError है , तो एक हमेशा उठाया जाता है, भले ही दोनों स्ट्रिंग समान हों।

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None) [source]

जोर देता है कि तार xml1 और समान नहीं xml2 हैं । तुलना एक्सएमएल शब्दार्थ पर आधारित है। विवरण के लिए देखें। assertXMLEqual()

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='') [source]

यह दावा करता है कि HTML टुकड़ा needle एक में समाहित है haystack

यदि count पूर्णांक तर्क निर्दिष्ट किया जाता है, तो इसके अलावा needle घटनाओं की संख्या को सख्ती से सत्यापित किया जाएगा।

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

SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None) [source]

यह बताता है कि JSON के टुकड़े raw और expected_data बराबर हैं। सामान्य JSON गैर-महत्वपूर्ण व्हाट्सएप नियम लागू होता है क्योंकि json लाइब्रेरी में हेवीवेट को प्रत्यायोजित किया जाता है।

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None) [source]

यह बताता है कि JSON के टुकड़े raw और बराबर नहीं expected_data हैं । अधिक जानकारी के लिए देखें। assertJSONEqual()

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

TransactionTestCase.assertQuerysetEqual(qs, values, transform=repr, ordered=True, msg=None) [source]

यह दावा करता है कि एक क्वेरीसेट qs मानों की एक विशेष सूची देता है values

की सामग्री की तुलना qs और values फ़ंक्शन का उपयोग करके किया जाता है transform ; डिफ़ॉल्ट रूप से, इसका मतलब है कि repr() प्रत्येक मूल्य की तुलना की जाती है। यदि repr() कोई अद्वितीय या सहायक तुलना प्रदान नहीं करता है तो किसी अन्य कॉल करने योग्य का उपयोग किया जा सकता है ।

डिफ़ॉल्ट रूप से, तुलना भी निर्भर करने का आदेश दे रही है। यदि qs कोई अंतर्निहित आदेश प्रदान नहीं करता है, तो आप ordered पैरामीटर को सेट कर सकते हैं False , जो तुलना को तुलना में बदल देता है collections.Counter । यदि आदेश अपरिभाषित है (यदि दिए गए qs आदेश का पालन नहीं किया गया है और तुलना एक से अधिक ऑर्डर किए गए मूल्यों के विरुद्ध है), तो एक ValueError उठाया जाता है।

त्रुटि के मामले में आउटपुट को msg तर्क के साथ अनुकूलित किया जा सकता है।

TransactionTestCase.assertNumQueries(num, func, *args, **kwargs) [source]

दावा करता है कि कब और func कहा जाता है कि डेटाबेस प्रश्नों को निष्पादित किया जाता है। *args **kwargs num

यदि इसमें कोई "using" कुंजी मौजूद है, तो kwargs इसे डेटाबेस उपनाम के रूप में उपयोग किया जाता है, जिसके लिए प्रश्नों की संख्या की जांच करें। यदि आप एक using पैरामीटर के साथ एक फ़ंक्शन को कॉल करना चाहते हैं, तो आप lambda अतिरिक्त पैरामीटर को जोड़ने के लिए कॉल को लपेटकर इसे कर सकते हैं :

self.assertNumQueries(7, lambda: my_function(using=7))

आप इसे संदर्भ प्रबंधक के रूप में भी उपयोग कर सकते हैं:

with self.assertNumQueries(2):
    Person.objects.create(name="Aaron")
    Person.objects.create(name="Daniel")

परीक्षण टैग करना

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

from django.test import tag

class SampleTestCase(TestCase):

    @tag('fast')
    def test_fast(self):
        ...

    @tag('slow')
    def test_slow(self):
        ...

    @tag('slow', 'core')
    def test_slow_but_core(self):
        ...

आप एक परीक्षण मामले को भी टैग कर सकते हैं:

@tag('slow', 'core')
class SampleTestCase(TestCase):
    ...

उपवर्गों को सुपरक्लास से टैग विरासत में मिले हैं, और विधियां अपनी कक्षा से टैग विरासत में मिली हैं। दिया हुआ:

@tag('foo')
class SampleTestCaseChild(SampleTestCase):

    @tag('bar')
    def test(self):
        ...

SampleTestCaseChild.test साथ लेबल किया जाएगा 'slow' , 'core' , 'bar' , और 'foo'

Django 2.1 में परिवर्तित:

पुराने संस्करणों में, टैग किए गए परीक्षण कक्षाओं से टैग विरासत में नहीं मिलते हैं, और टैग किए गए उपवर्ग सुपरक्लास से टैग विरासत में नहीं मिलते हैं। उदाहरण के लिए, SampleTestCaseChild.test केवल के साथ लेबल किया गया है 'bar'

फिर आप चुन सकते हैं कि कौन से परीक्षण चलाने हैं। उदाहरण के लिए, केवल तेज परीक्षण चलाने के लिए:

$ ./manage.py test --tag=fast
...\> manage.py test --tag=fast

या तेज परीक्षण और कोर एक को चलाने के लिए (भले ही यह धीमा हो):

$ ./manage.py test --tag=fast --tag=core
...\> manage.py test --tag=fast --tag=core

आप टैग द्वारा परीक्षणों को भी बाहर कर सकते हैं। धीमी गति से न होने पर मुख्य परीक्षण चलाने के लिए:

$ ./manage.py test --tag=core --exclude-tag=slow
...\> manage.py test --tag=core --exclude-tag=slow

test --exclude-tag पहले से अधिक है test --tag , इसलिए यदि एक परीक्षण में दो टैग हैं और आप उनमें से एक का चयन करते हैं और दूसरे को बाहर करते हैं, तो परीक्षण नहीं चलाया जाएगा।

ईमेल सेवाओं

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

परीक्षण धावक इसे सामान्य रूप से परीक्षण बैकएंड के साथ सामान्य ईमेल बैकएंड की जगह देकर पूरा करता है। (चिंता न करें - इसका Django के बाहर किसी भी अन्य ईमेल प्रेषक पर कोई प्रभाव नहीं पड़ता है, जैसे कि आपकी मशीन का मेल सर्वर, यदि आप एक हैं।)

django.core.mail.outbox

टेस्ट रनिंग के दौरान, प्रत्येक आउटगोइंग ईमेल को सेव किया जाता है django.core.mail.outbox । यह उन सभी EmailMessage उदाहरणों की एक सरल सूची है जो भेजे गए हैं। outbox विशेषता एक विशेष गुण है कि बनाया जाता है केवल जब locmem ईमेल बैकएंड प्रयोग किया जाता है। यह सामान्य रूप से django.core.mail मॉड्यूल के भाग के रूप में मौजूद नहीं है और आप इसे सीधे आयात नहीं कर सकते। नीचे दिए गए कोड से पता चलता है कि इस विशेषता को सही तरीके से कैसे एक्सेस किया जाए।

यहाँ एक उदाहरण परीक्षण है जो django.core.mail.outbox लंबाई और सामग्री की जांच करता है :

from django.core import mail
from django.test import TestCase

class EmailTest(TestCase):
    def test_send_email(self):
        # Send message.
        mail.send_mail(
            'Subject here', 'Here is the message.',
            '[email protected]', ['[email protected]'],
            fail_silently=False,
        )

        # Test that one message has been sent.
        self.assertEqual(len(mail.outbox), 1)

        # Verify that the subject of the first message is correct.
        self.assertEqual(mail.outbox[0].subject, 'Subject here')

जैसा कि previously उल्लेख किया previously , टेस्ट आउटबॉक्स एक Django में हर परीक्षण की शुरुआत में खाली किया जाता है *TestCase । आउटबॉक्स को मैन्युअल रूप से खाली करने के लिए, खाली सूची को यहां असाइन करें mail.outbox :

from django.core import mail

# Empty the test outbox
mail.outbox = []

प्रबंधन आदेश

call_command() फ़ंक्शन के साथ प्रबंधन कमांड का परीक्षण किया जा सकता है । आउटपुट को एक StringIO उदाहरण में पुनर्निर्देशित किया जा सकता है :

from io import StringIO
from django.core.management import call_command
from django.test import TestCase

class ClosepollTest(TestCase):
    def test_command_output(self):
        out = StringIO()
        call_command('closepoll', stdout=out)
        self.assertIn('Expected output', out.getvalue())

लंघन परीक्षण

Unittest पुस्तकालय प्रदान करता है @skipIf और @skipUnless आप परीक्षण को छोड़ने के लिए अगर आप समय से आगे पता है कि उन परीक्षण कतिपय शर्तों के अधीन विफल करने जा रहे हैं अनुमति देने के लिए सज्जाकार।

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

इन परीक्षण लंघन व्यवहारों के पूरक के लिए, Django दो अतिरिक्त स्किप सज्जाकार प्रदान करता है। एक सामान्य बूलियन का परीक्षण करने के बजाय, ये सज्जाकार डेटाबेस की क्षमताओं की जांच करते हैं, और यदि डेटाबेस विशिष्ट सुविधा का समर्थन नहीं करता है तो परीक्षण को छोड़ दें।

डेकोरेटर डेटाबेस विशेषताओं का वर्णन करने के लिए एक स्ट्रिंग पहचानकर्ता का उपयोग करते हैं। यह स्ट्रिंग डेटाबेस कनेक्शन सुविधाओं की विशेषताओं से मेल खाती है। django.db.backends.BaseDatabaseFeatures डेटाबेस विशेषताओं की पूरी सूची के लिए वर्ग देखें जो कि लंघन परीक्षणों के लिए आधार के रूप में उपयोग किया जा सकता है।

skipIfDBFeature(*feature_name_strings) [source]

सजाए गए परीक्षण को छोड़ दें या TestCase यदि नामित डेटाबेस सुविधाओं के सभी समर्थित हैं।

उदाहरण के लिए, यदि डेटाबेस लेनदेन का समर्थन करता है तो निम्न परीक्षण निष्पादित नहीं किया जाएगा (उदाहरण के लिए, यह PostgreSQL के तहत नहीं चलेगा, लेकिन यह MySQL के साथ MySQL के तहत होगा):

class MyTests(TestCase):
    @skipIfDBFeature('supports_transactions')
    def test_transaction_behavior(self):
        # ... conditional test code
        pass
skipUnlessDBFeature(*feature_name_strings) [source]

सजाए गए परीक्षण को छोड़ दें या TestCase यदि नामित डेटाबेस सुविधाओं में से कोई भी समर्थित नहीं है

उदाहरण के लिए, निम्न परीक्षण केवल तभी निष्पादित किया जाएगा जब डेटाबेस लेनदेन का समर्थन करता है (उदाहरण के लिए, यह PostgreSQL के तहत चलेगा, लेकिन MySQL के साथ MyISAM तालिकाओं के तहत नहीं ):

class MyTests(TestCase):
    @skipUnlessDBFeature('supports_transactions')
    def test_transaction_behavior(self):
        # ... conditional test code
        pass

Original text