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

उम्मीदों

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

किसी भी सिस्टम को विकसित करते समय, आपको कम से कम तीन प्रकार के परीक्षणों को याद रखना होगा:

• यूनिट परीक्षण ऐसे परीक्षण हैं जो यह सत्यापित करते हैं कि कार्यों को उनकी आवश्यकता है।
• एकीकरण परीक्षण ऐसे परीक्षण हैं जो यह सत्यापित करते हैं कि कई कार्य एक साथ सही कार्य करते हैं।
• सिस्टम परीक्षण वे परीक्षण होते हैं जो यह सत्यापित करते हैं कि संपूर्ण सिस्टम वह करता है जिसकी उसे आवश्यकता है।

गूगल के एक पोस्ट में , तीन प्रकार के परीक्षणों के विवरण के साथ एक तालिका प्रकाशित की गई थी। "छोटा", "मध्यम" और "बड़ा"।

यूनिट परीक्षण

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

एकीकरण परीक्षण

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

सिस्टम परीक्षण

यह स्वचालित परीक्षण का उच्चतम स्तर है। सिस्टम परीक्षण यह सत्यापित करते हैं कि पूरी प्रणाली काम करती है, कि इसके हिस्से अपने कार्य करते हैं और सही ढंग से बातचीत करने में सक्षम हैं।

प्रकारों पर नज़र क्यों रखें

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

वास्तविकता

ठेठ एपीआई टेस्ट

def test_user_reg(client): return json.loads( client.post(url, json=data, content_type='application/json').data ) response = client.post('api/user.reg', json={ 'email': 'name@mail.ru', 'password': 'password1', 'first_name': 'Name', 'last_name': 'Last Name' }) data = json.loads(response.data) assert data['code'] == 0 

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

मॉड्यूलर के बजाय एकीकरण क्यों? क्योंकि क्वेरी प्रोसेसिंग में, इंटरेक्शन फ्लास्क के साथ, ORM के साथ, हमारे व्यावसायिक तर्क के साथ किया जाता है। हैंडलर परियोजना के अन्य हिस्सों के एकीकरण लिंक के रूप में कार्य करते हैं, इसलिए उनके लिए यूनिट परीक्षण लिखना बहुत आसान नहीं है (आपको डेटाबेस को नकली, आंतरिक तर्क के साथ बदलने की आवश्यकता है) और बहुत अधिक व्यावहारिक नहीं है (एकीकरण परीक्षण समान पहलुओं की जांच करेंगे - "आवश्यक कार्य कहा जाता था?", "," क्या डेटा सही ढंग से प्राप्त किया गया था? ”, आदि)।

नाम और परीक्षणों का समूह

 def test_not_empty_errors(): assert validate_not_empty('email', '') == ('email is empty',) assert validate_not_empty('email', ' ') == ('email is empty',) assert validate_email_format('email', "") == ('email is empty',) assert validate_password_format('pass', "") == ('pass is empty',) assert validate_datetime('datetime', "") == ('datetime is empty',) 

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

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

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

प्रतिगमन परीक्षण

 def test_datetime_errors(): assert validate_datetime('datetime', '0123-24-31T;431') == ('datetime is invalid',) assert validate_datetime('datetime', '2018-10-18T20:21:21+-23:1') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-13-20T20:20:20+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-02-29T20:20:20+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T25:20:20+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:61:20+22:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:20:61+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:20:20+25:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:20:20+20:61') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-13-35T25:61:61+61:61') == ('datetime is invalid',) 

इस परीक्षण में मूल रूप से पहले दो assert । उसके बाद, एक "बग" की खोज की गई - तारीख की जांच करने के बजाय, केवल नियमित अभिव्यक्ति की जांच की गई, अर्थात। 9999-99-99 को एक सामान्य तारीख माना जाता था। डेवलपर ने इसे ठीक कर दिया। स्वाभाविक रूप से, बग को ठीक करने के बाद, आपको भविष्य के प्रतिगमन को रोकने के लिए परीक्षणों को जोड़ने की आवश्यकता है। एक नया परीक्षण जोड़ने के बजाय जिसमें यह लिखना है कि यह परीक्षण क्यों मौजूद है, इस परीक्षण में चेक जोड़े गए हैं।

सत्यापन को जोड़ने के लिए एक नई परीक्षा को क्या कहा जाना चाहिए? संभवतः test__validate_datetime__error_on_bad_datetime ।

उपकरणों की अनदेखी

 def test_get_providers(): class Tmp: def __init__(self, id_external, token, username): self.id_external = id_external self.token = token self.username = username ... 

Tmp ? यह एक ऑब्जेक्ट के लिए एक प्रतिस्थापन है जिसका उपयोग इस परीक्षण में नहीं किया गया है। डेवलपर को MagicMock से @patch और MagicMock के अस्तित्व के बारे में पता नहीं लगता है। अधिक पर्याप्त उपकरण होने पर समस्याओं को भली-भांति हल करके कोड को जटिल करने की आवश्यकता नहीं है।

ऐसा एक परीक्षण है जो सेवाओं को शुरू करता है (डेटाबेस में), अनुप्रयोग संदर्भ का उपयोग करता है।

 def test_get_posts(client): def fake_request(*args, **kwargs): return [one, two] handler = VKServiceHandler() handler.request = fake_request services_init() with app.app_context(): posts = handler.get_posts(None) assert len(posts) == 2 

आप डेटाबेस और संदर्भ को केवल एक @patch जोड़कर परीक्षण से बाहर कर सकते हैं।

 @patch("mobius.services.service_vk.Service") def test_get_posts(mock): def fake_request(*args, **kwargs): return [one, two] handler = VKServiceHandler() handler.request = fake_request posts = handler.get_posts(None) assert len(posts) == 2 

परिणाम

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

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