Yii, निरंतर एकीकरण - कैसे सब कुछ तोड़ने के लिए नहीं

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

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

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

"चलो सावधान रहें" / "चलो गलतियाँ न करें" - मैंने डेवलपर्स को बुलाया, लेकिन इससे केवल अस्थायी रूप से मदद मिली और फिर 100% तक नहीं। लोग गलतियाँ करते हैं, भूल करते हैं, गलतियाँ करते हैं। नहीं, मैंने वेब-परियोजनाओं के लिए "सिल्वर बुलेट" का आविष्कार नहीं किया था और यहां तक ​​कि वाईआईई के लिए छोटी बुलेट - मैंने सोचा कि मेरे आवेदन को कैसे स्थिर किया जाए। आपका आवेदन मेरा अलग है और मेरे तरीके आपके लिए काम नहीं कर सकते हैं, और उन्हें नहीं करना चाहिए - मैंने उन्हें आपके आवेदन के लिए नहीं किया है, अगर मेरे तरीके आपके लिए काम करते हैं, तो इसे एक चमत्कार या भाग्य के रूप में लें। लेकिन ऐसे सीआई का विचार हर जगह काम करेगा। सिर्फ एक विचार।

क्या विचार है

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

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

यदि मॉडल के साथ सब कुछ सरल है, तो मुझे नियंत्रकों और एक्शन गेम्स के साथ टिंकर करना होगा। हमने तय किया कि किसी भी बाहरी कॉल (http, कंसोल) को एक घातक त्रुटि (http> = 500) का कारण नहीं होना चाहिए: कोई इकाई 404 का मतलब नहीं है, वक्र अनुरोध का मतलब 400, कोई एक्सेस 403 नहीं है। यदि इसे एक्सेस करते समय आपका नियंत्रक घातक है। एक आईडी के साथ जो मौजूद नहीं है या कुछ अन्य टेढ़े मापदंडों के साथ - यह http प्रोटोकॉल के दृष्टिकोण से गलत व्यवहार है - उपयोगकर्ता त्रुटि 4xx है, 5xx नहीं - आपको कुटिल अनुरोधों के साथ घातक परिणाम नहीं देना है, आपको उपयोगकर्ता को एक सार्थक त्रुटि देने की आवश्यकता है "वह क्या गलत करता है"।

दरअसल, इस सिद्धांत पर नियंत्रकों की जांच का निर्माण किया गया था - हम एक मॉड्यूल, एक नियंत्रक का निर्माण करते हैं, कार्रवाई को खींचते हैं - जो हुआ है उसे देखें - ExceptionPage404 - यह सामान्य है (हमने $ _GET को डेटा पास नहीं किया है), लेकिन FatalException या PHP त्रुटि पहले से ही खराब है - परीक्षण पास नहीं हुआ।

हमने Yii के घटकों को भी मानकीकृत किया है जो हम लिखते हैं। हमारे मामले में, कोई भी घटक मौजूदा Yii कार्यात्मक का एक विस्तार है। उदाहरण के लिए, शार्किंग, वैश्विक डेटाबेस कैश जोड़ना। इस तरह के एक कार्यात्मक एक साथ दो सार - Yii मॉडल और हमारे विस्तार घटक को लागू करता है। इसे 2 बार चेक भी किया जाता है - सभी मॉडलों के उदाहरण पर, और एक घटक के रूप में अलग से।

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

हमारे उदाहरण पर कार्यान्वयन

हमारे पास 4 विधानसभा चरण हैं:

• निर्भरता की तैनाती, प्रवास, स्थापना / अद्यतन - यह ऊपर वर्णित विचार से संबंधित नहीं है, बस कहें कि यह है।
• कोड गुणवत्ता की जाँच करें
• इंटरफ़ेस कोड सत्यापन - ऊपर वर्णित विचार का कार्यान्वयन।
• अक्सर पॉप-अप बग्स के लिए यूनिट-परीक्षणों की एक छोटी संख्या (दोनों सिर्फ फ़ापुनिट और सेलेनियम + फ़पुनिट)। वे बहुत कम ही "समर्थित" या जोड़े जाते हैं - इसलिए मैंने लिखा है कि "परीक्षणों पर एक दिन एन घंटे खर्च न करें" - मैं 1 परीक्षण लिखने पर प्रति माह 1 घंटे खर्च करता हूं, 1 कष्टप्रद बग पर।

एक कदम - तैनात

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

दो चरण - कोड गुणवत्ता

पहली चीज जिसे हम जांचते हैं: "php -l" - चाहे हमारे साथ सब कुछ पार्स हो - इसके बिना, आगे कोई मतलब नहीं है। दूसरी चीज जिसे हम कोड में देख रहे हैं वह है निषिद्ध कॉल: डाई, var_dump, ini_set, बाहर निकलें। फिर, सामान्य fgrep का उपयोग करते हुए, हम कुटिल मर्ज के परिणामों की तलाश करते हैं: "<<<<<<<<<", ">>>>>>", "======" - ऐसा कचरा कभी-कभी तब गिरता है जब आप अपने हाथों से एक गोपनीय स्थान रखते हैं। नोटिस नहीं किया और संघर्ष को हल नहीं किया।
हम नियमित अभिव्यक्ति के साथ निम्नलिखित की तलाश करते हैं:

• कोड की लंबी स्क्रीन के तरीके।
• बहुत नेस्टेड कोड जैसे "5 नेस्टेड इफ"
• फॉर्म प्रिंट का बहुत "लोडेड कोड" (preg_replace ('/ @ /', "/% /", "a" .substr (1, 5, $ लाला)) (Int) (बूल) $ d); - यह पढ़ना मुश्किल है, लिखना मुश्किल है और मैं ऐसे कोड को नहीं देखना चाहता।

चरण तीन - इंटरफ़ेस कोड सत्यापन

इसे कई "चरणों" में विभाजित किया गया है - मॉडल, नियंत्रक, घटक, सार्वभौमिक सेलेनियम चेक (हाँ, वहाँ एक भी है! मैं आपको थोड़ा बाद में बताऊंगा), पुस्तकालयों के साथ एकीकरण परीक्षण की जाँच करें।

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

परिणामस्वरूप, लूप में प्रत्येक मॉडल के लिए हम कुछ इस तरह करते हैं:

$model = ModelClass::createDefault(); //   $this->assertNotNull($model); //? $this->assertTrue($model->save()); //? $pk = $model->getPk(); // primary key $loaded = ModelClass::model()->findByPk($pk); //    primary key $this->assertNotNull($loaded); //? $this->assertTrue($model->delete()); //? $this->assertIsNull(ModelClass::model()->findByPk($pk)); //? 

हमने इस ट्रिकी टेस्ट के साथ निम्नलिखित किया: हमने सुनिश्चित किया कि शार्डिंग लेयर काम कर रही है, डेटाबेस कैश सामान्य ऑपरेशन में हस्तक्षेप नहीं करता है, डेटाबेस में टेबल सामान्य रूप से माइग्रेट हो गया है और यह मॉडल इस तालिका में सहेजा गया है (+ ट्रिगर्स नहीं गिरते हैं)।

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

• वैश्विक पेज बदलें
• टैब बदल दें
• डायलॉग बॉक्स खोलें
• डायलॉग बॉक्स में फॉर्म सबमिट करें

पहले तीन बिंदुओं को बहुत आसानी से स्वचालित किया गया था - वैश्विक पृष्ठ को बदलने वाले ए और बटन टैग में वैश्विक सीएसएस वर्ग है, बदलते टैब में डेटा-टैब विशेषता है, उद्घाटन के संवादों में डेटा-एमएसबॉक्स विशेषता है। यह हमारे लिए 3 नेस्टेड लूप बनाने के लिए पर्याप्त था: पृष्ठ को बदलता है (बटन पर बेवकूफ क्लिक करता है), टैब बदलता है (बटन भी दबाता है), संवाद खोलता है (और सिर्फ क्लिक भी करता है)। प्रत्येक नेस्टेड चरणों में, हम जांचते हैं कि क्या पृष्ठ की सामग्री बदल गई है, चाहे div में सामग्री टैब के लिए बदल गई है, या यदि कोई संवाद खुल गया है। रास्ते में, हम ब्राउज़र से js त्रुटियाँ एकत्र करते हैं।
रूपों के साथ, यह थोड़ा मुश्किल था। हमें संभव मान्य डेटा - डेटा-प्रकार = "ईमेल", "anyString", "चेकबॉक्स चेक किया गया", "फोन", "anyFile", और अन्य के मूल्यों के साथ डेटा तत्वों के प्रकारों को प्रपत्र तत्वों में जोड़ना था। और वहाँ तुम जाओ! प्रपत्र मानकीकृत हैं और हमारे पास सभी इनपुट के लिए एक सामान्य इंटरफ़ेस है - जिन क्षेत्रों में मान्य ईमेल हम ईमेल में भरते हैं, फोन के साथ क्षेत्रों में - फोन, और इसी तरह सभी क्षेत्रों में। हम फ़ॉर्म सबमिट करते हैं और सत्यापित करते हैं कि संवाद त्रुटियों के बिना बंद हो जाता है - इसका मतलब है कि डेटा सहेजा गया है। फिर हम उसी डेटा को अमान्य डेटा के साथ दोहराते हैं, उदाहरण के लिए, ईमेल फ़ील्ड में हम फोन लिखते हैं - और जांचें कि फॉर्म नहीं भेजा गया है, और उपयोगकर्ता के लिए एक त्रुटि दिखाई दी है।
मैंने फार्म क्षेत्रों में विशेषताओं को जोड़कर लगभग 1.5 घंटे बिताए। और हमारे पास कुछ रूप नहीं हैं - यह सिर्फ एक सरल काम है और यदि आप बैठते हैं और इसे करते हैं, तो इसमें अधिक समय नहीं लगेगा।

इस सरल (या शायद मुश्किल) विधि के साथ, हमने इस विषय के लिए पूरे UI की जाँच की:

• पृष्ठ, टैब, विंडो खोलने पर घातक
• मान्य और अमान्य फ़ॉर्म भेजते समय फ़र्ज़ी।
• मान्य डेटा के साथ कौन से फ़ॉर्म सहेजे जाते हैं
• यह प्रपत्र अमान्य डेटा के साथ त्रुटियां देते हैं।

यूनिट परीक्षण और सेलेनियम परीक्षण

ईमानदारी से, बहुत कम, बहुत कम हैं। हम उन्हें केवल तभी जोड़ते हैं जब एक दोहराया बग दिखाई दिया हो और एक बार फिर परीक्षकों ने कहा "ठीक है, यह फिर से काम नहीं कर रहा है!"
हम पुराने, लिखित परीक्षणों को कभी नहीं बदलते हैं - हम आवेदन को पिछड़ी संगतता में लेते हुए विकसित करते हैं। यह न केवल परीक्षणों के लिए आवश्यक है - आवेदन में सेल फोन / डेस्कटॉप के लिए एक एपीआई है और यह पिछड़े संगत होना चाहिए।

तो आगे क्या है?

थोड़ी देर बाद, हमने अपना js कोड मानकीकृत किया और इसे कवर किया (testit comrade titulusdesiderio के लिए धन्यवाद - हमने इसे नोडज के तहत चलाने के लिए अनुकूलित किया और वहां हम अपने js का परीक्षण करते हैं)
बाद में, हमने css + html टाइपसेटिंग परीक्षणों को कवर किया - हमने वक्रता के विषय के लिए, अलग-अलग स्क्रीनशॉट का उपयोग करके ध्वस्त टाइपसेटिंग की जांच की।
यदि आप निश्चित रूप से रुचि रखते हैं, तो मैं इस सब के बारे में अलग से बात करूंगा।

PS वाक्यांशों के साथ डांटने से पहले "यह परीक्षण नहीं है", "यह कार्यक्षमता का 5% कवर करता है" और इस तरह: हम परीक्षण नहीं करते हैं। हम वास्तव में एक प्रदर्शन की जाँच कर रहे हैं।
यह जाँचना पसंद करता है कि प्रकाश स्टोर में है - हम इसकी ऊष्मा की जाँच नहीं करते हैं, हम उत्सर्जित प्रकाश को नहीं मापते हैं, हम इसे गलत कारतूस में पेंच करने की कोशिश नहीं करते हैं - हम सिर्फ यह जाँचते हैं कि यह चालू है। हम कोड के साथ भी ऐसा ही करते हैं। एक सरल और समर्थन मुक्त तरीके से।

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