परीक्षण शुरू करने का आसान तरीका

यदि आप एक PHP डेवलपर हैं, और विभिन्न कारणों से आपके अनुप्रयोगों के लिए परीक्षण नहीं लिखते हैं, तो यह लेख आपके लिए है। इसमें, मैं संक्षेप में दिखाने की कोशिश करूंगा कि कहां से शुरू करना है और क्या करना है ताकि लेखन परीक्षण आपको खुशी, और आपके आवेदन की स्थिरता लाए।

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

मुझे पूरा यकीन है कि PHP प्रोग्रामर शायद ही कभी टेस्ट लिखते हैं क्योंकि वे गलत अंत से शुरू होते हैं। हर कोई जानता है कि परीक्षण अच्छे और शांत हैं। लेकिन एक ही PHPUnit की वेबसाइट खोली है, और एक कैलकुलेटर का परीक्षण करने के बारे में एक रंगीन उदाहरण पढ़ा है जो जानता है कि a + b ऑपरेशन कैसे करें, वे खुद से पूछते हैं: इस कैलकुलेटर का मेरे आवेदन के साथ क्या करना है? उत्तर: नहीं। अन्य परीक्षण रूपरेखाओं की साइटों पर सभी समान उदाहरणों की तरह बिल्कुल। जैसे कि हर कोई भूल गया था कि PHP मुख्य रूप से वेब के लिए है। जैसे कि हर कोई कैलकुलेटर लिखता है, एमवीसी प्रतिमान पर आधारित साइटें नहीं।

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

और इसलिए हम कार्यात्मक परीक्षणों (या स्वीकृति परीक्षणों) के बारे में बात करेंगे।

कार्यात्मक परीक्षण सॉफ्टवेयर परीक्षण है, जिसमें कार्यात्मक आवश्यकताओं की व्यवहार्यता को सत्यापित किया जाता है, अर्थात्, कुछ परिस्थितियों में उपयोगकर्ताओं को जिन कार्यों की आवश्यकता होती है, उन्हें हल करने की सॉफ्टवेयर की क्षमता। कार्यात्मक आवश्यकताएं निर्धारित करती हैं कि सॉफ्टवेयर क्या करता है, यह किस कार्य को हल करता है।

विकिपीडिया

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

हमारे पास कार्यात्मक परीक्षण के लिए क्या है? मेरे लिए ज्ञात सभी में से, यह कोडैप्शन है और, उदाहरण के लिए, PHPUnit + मिंक या सेलेनियम का प्रत्यक्ष उपयोग। मैं इस कुकी में बेहट को शामिल करना चाहता था, लेकिन इसके लेखक ने मुझे कार्यात्मक परीक्षण के लिए बेहट का उपयोग नहीं करने के लिए कहा।

यदि सेलेनियम या PHPUnit + मिंक के साथ परीक्षण करना आसान था, तो आप शायद उनका उपयोग करेंगे। इसलिए, हम संहिता पर ध्यान केन्द्रित करते हैं।

परीक्षण निम्नानुसार वर्णित है:

<?php $I = new WebGuy($scenario); $I->wantTo('see my site is working'); $I->amOnPage('/'); $I->see('Welcome, on my site!'); ?> 

कुछ ही पंक्तियों में, आप जाँचते हैं कि आपकी साइट का मुख्य पृष्ठ कम से कम खुलता है। लंबे काम के लिए, इसे तोड़ना इतना मुश्किल नहीं है।
इसी तरह, आप आगे के कार्यों का वर्णन कर सकते हैं:

 <?php $I->click('Feedback'); $I->see('Submit your feedback'); $I->fillField('Body','Your site is great!'); $I->click('Submit'); $I->see('Thanks for your feedback!'); ?> 

यहां हम पहले से ही जांच लेते हैं कि आपकी साइट पर फीडबैक फॉर्म काम करता है। कम से कम उपयोगकर्ता को, यह दिखाया गया है कि उसकी राय को ध्यान में रखा गया है।

हालाँकि, Habré पर मैंने पहले से ही Codeception के बारे में लिखा था ।

अब इकाई परीक्षणों पर निर्णय लेने का प्रयास करते हैं।

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

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

विकिपीडिया ।

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

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

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

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

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

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

इकाई परीक्षण के लिए, कई रूपरेखाएँ हैं:

• PHPUnit
• Atoum
• EnhancePHP
• SimpleTest
• गवाही देना

पारंपरिक इकाई परीक्षणों के विकल्प के रूप में:

• PHPSpec
• स्पेक्ट्रम ( रूसी में उत्कृष्ट प्रलेखन के साथ)।
• एक ही तरह की धारणा। अजीब तरह से, मैंने उसके बारे में भी लिखा ।

फिर से, अपने लिए चुनें। PHPUnit, निश्चित रूप से, मानक है, लेकिन अधिक आधुनिक रूपरेखा सरल और अधिक कुशल हो सकती है।

संक्षेप में, मैं यह कहूंगा कि परीक्षण वास्तव में आवश्यक हैं और वे उतने डरावने नहीं हैं जितना आप सोच सकते हैं। स्वीकृति परीक्षणों के साथ परीक्षण लिखना शुरू करें, मॉड्यूलर जारी रखें। जो महत्वपूर्ण है उसे परखें और जो आप निश्चित नहीं हैं उसे परखें ।

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