परीक्षण के साथ काम शुरू होता है।

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

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

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

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



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



प्रपत्र काम करता है, डेटा सफलतापूर्वक सहेजा जाता है, ग्राहक संतुष्ट होता है। लेकिन अचानक ग्राहक को गुस्सा आ जाता है, "तो वे कहते हैं, ऑर्डर आ गया है - करोड़पति कंपनी मुझसे सभी ईंटें खरीदना चाहती है, लेकिन फोन नंबर फॉर्म से नहीं आया है और अब मैं उनसे कैसे संपर्क कर सकता हूं!" कल वे एक और आपूर्तिकर्ता मिल जाएगा! आपने ऐसा कैसे किया? यह आपकी गलती है ... " ग्राहक आँसू और tosses, माइनस नसों, माइनस ट्रस्ट और माइनस सम्मान। एक जूनियर के लिए स्थिति बेहद मानक है - फॉर्म से आने वाले डेटा की किसी भी मान्यता और परीक्षण की अनुपस्थिति। पहला कार्य (सत्यापन) केवल सत्यापन नियमों को जोड़कर हल किया जाता है:



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



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

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

हम पहले की तरह कार्य छोड़ देते हैं, हम केवल इसके लिए दृष्टिकोण बदलते हैं। हमें फील्ड फियो, फोन, कॉर्प, क्वांट और कंटेंट के साथ एक फॉर्म हैंडलर लिखना होगा। सफल निष्पादन का परिणाम स्थिति 200 है, मैसेज "ओके" के साथ ऑर्डर में एक फ़ील्ड जोड़ना और दर्ज किए गए रिकॉर्ड पर डेटा वापस करना, अन्य विकल्प - स्थिति 400 और त्रुटियों की सूची।

सबसे पहले, हमें फ़ॉर्म डेटा को वैध रूप से भरने के लिए एक परीक्षण विधि लिखने की आवश्यकता है:



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



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



हमारे चेक जगह में हैं, आप चला सकते हैं और चेक कर सकते हैं



आदर्श। हमारा एप्लिकेशन 5 में से 5 परीक्षणों में दुर्घटनाग्रस्त हो गया। हमारा आगे का लक्ष्य परीक्षण विधियों से गुजरना है जो अवैध मानों को फ़ील्ड में सेट करते हैं और आने वाले डेटा के लिए सत्यापन नियम बनाते हैं। तर्क कुछ इस तरह है: फियो फील्ड खाली नहीं हो सकता; लंबाई 3 से कम नहीं और 120 से अधिक नहीं; यह नाम (अक्षर, हाइफ़न, इंडेंट) में अनुमत वर्णों के समूह के साथ एक स्ट्रिंग है। सभी क्षेत्रों में इस तर्क का परिणाम:



फ़ाइल के जवाब में, त्रुटियों की एक सूची में त्रुटियों को जोड़ा गया है जो प्रत्येक "समस्या" फ़ील्ड के अनुरूप हैं। यह हमें सत्यापन के लिए विशिष्ट क्षेत्रों की जाँच करने में मदद करेगा (परीक्षण फ़ाइल में assertJsonStructure)। अगला, हम सत्यापन के लिए विधि जोड़ते हैं और अंतिम संस्करण प्राप्त करते हैं:



और अंत में, हम जांच सकते हैं कि हमारी स्क्रिप्ट परीक्षण का काम कैसे करती है (मुझे याद है, 5 परीक्षणों में 5 असफल थे)।



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



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