फ्लास्क मेगा-ट्यूटोरियल, भाग 7: यूनिट परीक्षण

यह एक श्रृंखला का सातवाँ लेख है जहाँ मैं फ्लास्क माइक्रोफ़्रामवर्क का उपयोग करते हुए पायथन वेब एप्लिकेशन लिखने के अपने अनुभव का वर्णन करता हूँ।



इस गाइड का उद्देश्य एक काफी कार्यात्मक माइक्रोब्लॉगिंग एप्लिकेशन विकसित करना है, जिसे मैंने मौलिकता की अनुपस्थिति में माइक्रोब्लॉग को कॉल करने का निर्णय लिया।

संक्षिप्त पुनरावृत्ति

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



आज हम नई सुविधाओं को नहीं जोड़ेंगे। इसके बजाय, हम पहले से ही लिखित कोड को और अधिक स्थिर बनाने की कोशिश करेंगे, और अपना स्वयं का ढांचा भी बनाएंगे, जो भविष्य में हमें संभावित दुर्घटनाओं को रोकने में मदद करेगा।

बग खोज

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



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



इससे पहले कि हम इन समस्याओं को हल करें, एक नज़र डालते हैं कि जब कोई त्रुटि होती है, तो एप्लिकेशन कैसे व्यवहार करता है।

फ्लास्क में डिबगिंग

सबसे पहले, एक नया डेटाबेस बनाएं। यदि आपके पास लिनक्स है:

rm app.db ./db_create.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

विंडोज:

 del app.db flask/Scripts/python db_create.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

बग खेलने के लिए आपको दो OpenID खातों की आवश्यकता होगी, यह बेहतर है यदि ये खाते विभिन्न प्रदाताओं से हैं, अन्यथा कुकीज़ के साथ कुछ कठिनाइयां हो सकती हैं। तो, प्रक्रिया इस प्रकार है:

• अपने पहले खाते का उपयोग करके लॉग इन करें।
• प्रोफाइल एडिट पेज पर, उपनाम को 'dup' में बदलें
• लॉग आउट करें
• अपने दूसरे खाते से प्रवेश करें
• प्रोफाइल एडिट पेज पर, उपनाम को 'dup' में बदलें

ऊप्स! हमें sqlalchemy के कारण अपवाद मिला। त्रुटि पाठ पढ़ता है:

 sqlalchemy.exc.IntegrityError IntegrityError: (IntegrityError) UNIQUE constraint failed: user.nickname u'UPDATE user SET nickname=?, about_me=? WHERE user.id = ?' (u'dup', u'', 2)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

नीचे इस त्रुटि का एक स्टैक ट्रेस है , जिसमें आप न केवल प्रत्येक फ्रेम के स्रोत कोड को देख सकते हैं, बल्कि अपने कोड को सीधे ब्राउज़र में भी निष्पादित कर सकते हैं!



त्रुटि विवरण बहुत स्पष्ट है। उपयोगकर्ता को असाइन करने का प्रयास करने वाला उपनाम पहले से ही डेटाबेस में है। ध्यान दें कि User



मॉडल में, nickname



फ़ील्ड unique=True



रूप में घोषित किया गया है, यही वजह है कि यह स्थिति उत्पन्न हुई।



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



इस समय, हमारे आवेदन ने रिलीज़ मोड में काम किया। यह मोड स्टार्टअप पर debug=True



run



पद्धति के लिए दिया गया debug=True



तर्क का उपयोग करके सक्रिय किया गया है। जब हम लड़ाई सर्वर पर एप्लिकेशन लॉन्च करते हैं, तो यह सुनिश्चित करना आवश्यक होगा कि डिबगिंग मोड बंद है। इसके लिए, हमें एक और स्क्रिप्ट ( runp.py



file) की आवश्यकता है :

 #!flask/bin/python from app import app app.run(debug = False)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अब इस स्क्रिप्ट का उपयोग करके एप्लिकेशन को चलाएं

 ./runp.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

दूसरे खाते के उपनाम को फिर से 'डिप' में बदलने का प्रयास करें। इस बार हम एक विस्तृत त्रुटि संदेश नहीं देखेंगे। इसके बजाय, हमें 500 Internal Server Error



कोड के साथ एक HTTP त्रुटि मिलती है। यह फ्लास्क पेज तब उत्पन्न होता है जब डिबगिंग मोड बंद हो जाता है और एक अपवाद होता है। पृष्ठ ऐसा दिखता है, लेकिन कम से कम हम एप्लिकेशन के बारे में अनावश्यक विवरण प्रकट नहीं करते हैं।



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

मूल HTTP त्रुटि हैंडलर

फ्लास्क अनुप्रयोगों को त्रुटियों को प्रदर्शित करने के लिए अपने स्वयं के पृष्ठों का उपयोग करने की अनुमति देता है। एक उदाहरण के रूप में, हम अपने पृष्ठों को ४०४ और ५०० त्रुटियों के लिए लागू करते हैं, क्योंकि वे सबसे अधिक सामना करते हैं। अन्य त्रुटियों के लिए, आपके अपने पृष्ठ बनाने की प्रक्रिया ठीक उसी तरह होगी।



अपने स्वयं के त्रुटि हैंडलर को घोषित करने के लिए, हमें errorhandler



डेकोरेटर (फ़ाइल app/views.py



errorhandler



) की app/views.py



:

 @app.errorhandler(404) def not_found_error(error): return render_template('404.html'), 404 @app.errorhandler(500) def internal_error(error): db.session.rollback() return render_template('500.html'), 500
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मुझे नहीं लगता कि इस कोड को स्पष्टीकरण की आवश्यकता है। केवल ध्यान देने योग्य अभिव्यक्ति यहाँ db.session.rollback()



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



404 त्रुटि के लिए टेम्प्लेट:

 <!-- extend base layout --> {% extends "base.html" %} {% block content %} <h1>File Not Found</h1> <p><a href="{{url_for('index')}}">Back</a></p> {% endblock %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और त्रुटि 500 ​​के लिए एक टेम्प्लेट भी:

 <!-- extend base layout --> {% extends "base.html" %} {% block content %} <h1>An unexpected error has occurred</h1> <p>The administrator has been notified. Sorry for the inconvenience!</p> <p><a href="{{url_for('index')}}">Back</a></p> {% endblock %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

दोनों ही मामलों में, हम अभी भी मूल पेज के रूप में base.html



उपयोग करते हैं, जिसके परिणामस्वरूप दोनों HTTP त्रुटि संदेश हमारे माइक्रोब्लॉग के बाकी पृष्ठों के समान शैली में दिखते हैं।

मेल करने के लिए त्रुटि संदेश भेजना

दूसरी समस्या को हल करने के लिए, हम दो एप्लिकेशन एरर रिपोर्टिंग सिस्टम सेट करेंगे। हर बार त्रुटि होने पर पहला ईमेल हमें भेजेगा।



सबसे पहले, हमें मेल सर्वर और हमारे आवेदन के प्रशासकों की सूची को कॉन्फ़िगर करने की आवश्यकता है। ( config.py



) :

 # mail server settings MAIL_SERVER = 'localhost' MAIL_PORT = 25 MAIL_USERNAME = None MAIL_PASSWORD = None # administrator list ADMINS = ['you@example.com']
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

बेशक, आपको इन मूल्यों को बदलने की आवश्यकता है।



फ्लास्क पायथन मानक पुस्तकालय से logging



मॉड्यूल का उपयोग करता है, इसलिए ईमेल पर त्रुटि संदेश भेजने की स्थापना काफी सरल होगी ( app/__init__.py



) :

 from config import basedir, ADMINS, MAIL_SERVER, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD if not app.debug: import logging from logging.handlers import SMTPHandler credentials = None if MAIL_USERNAME or MAIL_PASSWORD: credentials = (MAIL_USERNAME, MAIL_PASSWORD) mail_handler = SMTPHandler((MAIL_SERVER, MAIL_PORT), 'no-reply@' + MAIL_SERVER, ADMINS, 'microblog failure', credentials) mail_handler.setLevel(logging.ERROR) app.logger.addHandler(mail_handler)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यदि डिबगिंग मोड बंद है तो हम केवल ये ईमेल भेजेंगे। यदि आपके पास मेल सर्वर कॉन्फ़िगर नहीं है तो यह ठीक है। हमारे उद्देश्यों के लिए, SMTP डिबग सर्वर, जो पायथन हमें प्रदान करता है, काफी उपयुक्त है। इसे शुरू करने के लिए, कंसोल में टाइप करें (या कमांड लाइन पर यदि आप एक Windows उपयोगकर्ता हैं):

 python -m smtpd -n -c DebuggingServer localhost:25
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

किसी फ़ाइल में लॉग इन करना

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



सेटअप प्रक्रिया बहुत कुछ वैसा ही है जैसा हमने सिर्फ मेल के लिए किया था (फ़ाइल app/__init__.py



)

 if not app.debug: import logging from logging.handlers import RotatingFileHandler file_handler = RotatingFileHandler('tmp/microblog.log', 'a', 1 * 1024 * 1024, 10) file_handler.setFormatter(logging.Formatter('%(asctime)s %(levelname)s: %(message)s [in %(pathname)s:%(lineno)d]')) app.logger.setLevel(logging.INFO) file_handler.setLevel(logging.INFO) app.logger.addHandler(file_handler) app.logger.info('microblog startup')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लॉग को tmp



फ़ोल्डर में microblog.log



नाम से सहेजा जाएगा। हमने RotatingFileHandler



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



logging.Formatter



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



लॉग को अधिक उपयोगी बनाने के लिए, हम दोनों app.logger



और file_handler



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



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

बग ठीक करना

तो, चलो अंत में बग को उसी उपनाम से ठीक करें।



जैसा कि पहले उल्लेख किया गया है, हमारे पास दो समस्या क्षेत्र हैं जहां डुप्लिकेट चेकिंग गायब है। पहला after_login



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

 if user is None: nickname = resp.nickname if nickname is None or nickname == "": nickname = resp.email.split('@')[0] nickname = User.make_unique_nickname(nickname) user = User(nickname = nickname, email = resp.email, role = ROLE_USER) db.session.add(user) db.session.commit()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हमारा समाधान एक अद्वितीय उपनाम बनाने के लिए उपयोगकर्ता वर्ग को निर्देश देना है। इसे इसी तरह लागू किया जाता है (फ़ाइल app/models.py



) :

 class User(db.Model): # ... @staticmethod def make_unique_nickname(nickname): if User.query.filter_by(nickname = nickname).first() == None: return nickname version = 2 while True: new_nickname = nickname + str(version) if User.query.filter_by(nickname = new_nickname).first() == None: break version += 1 return new_nickname # ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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



विधि ( app/forms.py



) को ओवरलोड करना होगा:

 from app.models import User class EditForm(Form): nickname = TextField('nickname', validators = [Required()]) about_me = TextAreaField('about_me', validators = [Length(min = 0, max = 140)]) def __init__(self, original_nickname, *args, **kwargs): Form.__init__(self, *args, **kwargs) self.original_nickname = original_nickname def validate(self): if not Form.validate(self): return False if self.nickname.data == self.original_nickname: return True user = User.query.filter_by(nickname = self.nickname.data).first() if user != None: self.nickname.errors.append('This nickname is already in use. Please choose another one.') return False return True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

प्रपत्र निर्माता अब एक नया तर्क स्वीकार करता है - original_nickname



। validate



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



हम एक नए तर्क के साथ फ़ॉर्म को आरंभ करते हैं:

 @app.route('/edit', methods = ['GET', 'POST']) @login_required def edit(): form = EditForm(g.user.nickname) # ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हमें उन सभी त्रुटियों को भी प्रदर्शित करने की आवश्यकता है जो प्रपत्र सत्यापन के दौरान होती हैं, जिस क्षेत्र में त्रुटि का पता लगाया जाता है, उसके बगल में। (फ़ाइल app/templates/edit.html



) :

 <td>Your nickname:</td> <td> {{form.nickname(size = 24)}} {% for error in form.errors.nickname %} <br><span style="color: red;">[{{error}}]</span> {% endfor %} </td>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह सब, डुप्लिकेट के साथ समस्या हल हो गई है! यह सच है, हमारे पास अभी भी कई थ्रेड्स या प्रक्रियाओं से डेटाबेस तक एक साथ पहुंचने की संभावित समस्या है, लेकिन यह विषय भविष्य के लेख में शामिल किया जाएगा।



अब आप फिर से उपनाम को मौजूदा एक में बदलने की कोशिश कर सकते हैं और सुनिश्चित कर सकते हैं कि कोई और समस्या नहीं है।

परीक्षण रूपरेखा

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



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



आइए, सबसे छोटे मॉड्यूल (फ़ाइल app/tests.py



) का उपयोग करके एक छोटा परीक्षण ढाँचा लिखें:

 #!flask/bin/python import os import unittest from config import basedir from app import app, db from app.models import User class TestCase(unittest.TestCase): def setUp(self): app.config['TESTING'] = True app.config['CSRF_ENABLED'] = False app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///' + os.path.join(basedir, 'test.db') self.app = app.test_client() db.create_all() def tearDown(self): db.session.remove() db.drop_all() def test_avatar(self): u = User(nickname = 'john', email = 'john@example.com') avatar = u.avatar(128) expected = 'http://www.gravatar.com/avatar/d4c74594d841139328695756648b6bd6' assert avatar[0:len(expected)] == expected def test_make_unique_nickname(self): u = User(nickname = 'john', email = 'john@example.com') db.session.add(u) db.session.commit() nickname = User.make_unique_nickname('john') assert nickname != 'john' u = User(nickname = nickname, email = 'susan@example.com') db.session.add(u) db.session.commit() nickname2 = User.make_unique_nickname('john') assert nickname2 != 'john' assert nickname2 != nickname if __name__ == '__main__': unittest.main()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस लेख के दायरे से परे unittest



चर्चा है। यदि आप इस मॉड्यूल से परिचित नहीं हैं, तो आप बस मान सकते हैं कि हमारे परीक्षण TestCase



क्लास में हैं। setUp



और tearDown



विशेष महत्व के हैं, इन्हें क्रमशः प्रत्येक परीक्षण से पहले और बाद में निष्पादित किया जाता है। अधिक जटिल मामलों में, कई परीक्षण समूहों को परिभाषित किया जा सकता है, जहां प्रत्येक समूह unittest.TestCase



का एक उपवर्ग है, फिर प्रत्येक समूह का अपना setUp



और tearDown



।



हमारे मामले में, परीक्षण से पहले और बाद में किसी भी जटिल कार्यों की आवश्यकता नहीं है। setUp



, एप्लिकेशन का कॉन्फ़िगरेशन थोड़ा बदलता है। उदाहरण के लिए, हम परीक्षण के लिए एक अलग डेटाबेस का उपयोग करते हैं। tearDown



विधि में tearDown



हम डेटाबेस को साफ करते हैं।



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



इसलिए, हमारे ढांचे में दो परीक्षण हैं। पहले अवतार URL की जाँच करता है जिसे हमने पिछले अध्याय में लागू किया था। दूसरा परीक्षण make_unique_nickname



विधि की जाँच करता है जो हमने अभी उपयोगकर्ता वर्ग के लिए लिखा था। सबसे पहले, एक उपयोगकर्ता 'जॉन' नाम से बनाया गया है। डेटाबेस में संग्रहीत होने के बाद, परीक्षण विधि को 'जॉन' के अलावा एक उपनाम वापस करना चाहिए। फिर हम सुझाए गए उपनाम के साथ दूसरा उपयोगकर्ता बनाते और सहेजते हैं और सत्यापित करते हैं कि make_unique_nickname



लिए एक और कॉल दोनों निर्मित उपयोगकर्ताओं के नामों से अलग नाम लौटाएगा।



परीक्षण चलाएँ:

 ./tests.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यदि कोई त्रुटि होती है, तो उन्हें कंसोल में प्रदर्शित किया जाएगा।

अंतिम शब्द

यह डिबगिंग, त्रुटियों और परीक्षण की हमारी चर्चा का समापन करता है। मुझे उम्मीद है कि आपको यह लेख अच्छा लगा होगा। हमेशा की तरह, यदि आपके कोई प्रश्न हैं, तो उन्हें टिप्पणियों में पूछें।



नवीनतम माइक्रोब्लॉगिंग कोड निम्नलिखित लिंक पर डाउनलोड किया जा सकता है:

माइक्रोब्लॉग-0.7.zip डाउनलोड करें



हमेशा की तरह, कोई आभासी वातावरण या डेटाबेस नहीं है। उनके निर्माण की प्रक्रिया पिछले लेखों में वर्णित है।



जल्द मिलते हैं!



मिगुएल