TDD को django और पोस्टग्रेज के साथ कार्यान्वित करें

Ostrovka में दो मुख्य उत्पाद हैं: उपयोगकर्ताओं के लिए (ostrovok.ru) और होटलों के लिए "व्यवस्थापक" (एक्स्ट्रानेट) , जहां हमने जिन होटलों पर हस्ताक्षर किए हैं वे डेटा दर्ज करते हैं। ये अलग-अलग उत्पाद हैं, अपनी टीमों के साथ और परीक्षण (टीडीडी) के माध्यम से विकास के प्रति अलग-अलग दृष्टिकोण। एक ही मंच: django और postgres। वे एक्स्ट्रानेट पर टीडीडी का उपयोग करते हैं और परीक्षणों का एक गुच्छा है। प्रारंभ में, परीक्षण भी ostrovok.ru में थे, लेकिन कुछ अनुयायियों के एक्स्ट्रानेट और बहुत गहन विकास के प्रस्थान के कारण, उनका समर्थन करना बंद हो गया। सामान्य तौर पर, मुझे परीक्षण को लागू करने की चुनौती का सामना करना पड़ा। पहले कदम उठाए गए हैं और मैं इस अनुभव और समाधान को लागू करना चाहता हूं।

हमारे पास एक क्यूए और सेलेनियम ऑटोटेस्ट्स विभाग है, लेकिन यह अलग है।

Django और परीक्षणों के साथ, सामान्य तौर पर, चीजें बहुत अच्छी होती हैं, और निश्चित रूप से बहुत शुरुआत से परीक्षणों के साथ सब कुछ कवर करना बेहतर होता है, कार्यक्षमता बढ़ाना और रिफैक्टरिंग करना।

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

मुझे क्या परीक्षण पसंद हैं और क्यों TDD

कई प्रकार के परीक्षण हैं जो विभिन्न पहलुओं में भिन्न हैं।

अलगाव में, मुझे एकीकरण परीक्षण अधिक पसंद हैं; परीक्षण के तहत वस्तु में, मुझे कार्यात्मक परीक्षण पसंद हैं।

ऐसे परीक्षणों में बहुत बड़ी कोड कवरेज होती है, जो एक ही समय में प्लस और माइनस दोनों होती है।

कम:

• कभी-कभी टूटी हुई जगह ढूंढना मुश्किल होता है

पेशेवरों:

• अजगर एक व्याख्या की गई भाषा है, कोड निष्पादन के क्षण में त्रुटियां सामने आ सकती हैं, और यदि यह परीक्षणों से आच्छादित है, तो हम आत्मविश्वास से कह सकते हैं कि यह कोड दुर्घटनाग्रस्त नहीं होता है;

• इस तरह के परीक्षण उच्च-स्तरीय हैं, और हम अक्सर कार्यान्वयन विवरण से डरते नहीं हैं, अर्थात्। आपको उन्हें कम संपादित करने की आवश्यकता है, हालांकि निश्चित रूप से आपको उन्हें संपादित करना होगा।

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

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

और निश्चित रूप से ऐसे स्थान हैं जहां मैनुअल परीक्षण मुश्किल या लगभग असंभव है, जिस स्थिति में परीक्षण एक आवश्यकता है। उदाहरण के लिए: अपवादों और त्रुटि से निपटने, तर्क के नाजुक स्थानों की सही पकड़ की जाँच ...

आदर्श रूप में, एक परीक्षण पहले।

परीक्षण के माध्यम से विकास के सभी लाभों का वर्णन करना इस लेख का उद्देश्य नहीं है, हम इसे दूसरों के लिए छोड़ देंगे, उदाहरण के लिए, केंट बेक ।

रनिंग टेस्ट कैसे तेज करें?

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

Django में, यह एक समस्या है , यह प्रत्येक परीक्षण चलाने से पहले एक डेटाबेस बनाता है, और यदि सर्किट बड़ा है, तो इसमें 30 सेकंड लग सकते हैं, और एक विशिष्ट परीक्षण में एक सेकंड से भी कम समय लगता है। मैं आधार बनने तक इंतजार नहीं करना चाहता।

समाधान: डेटाबेस का निर्माण एक अलग चरण में करें (पिछले रनों से डेटाबेस का उपयोग करें)।

हमारी शर्तों के तहत, आधार योजना के अलावा, हमें प्रारंभिक डेटा भी चाहिए:

• एक अलग आंतरिक जीआईएस सेवा के साथ, सेवा स्वयं एक REST इंटरफ़ेस प्रदान करके अपना जीवन व्यतीत करती है;

• http परीक्षणों में अक्सर व्यस्त होटलों की आवश्यकता होती है।

ऐसा लगता है कि नया क्या है:

• django में फिक्स्चर हैं , हालांकि वे स्थिर हैं और उन्हें बनाए रखना बहुत अच्छा नहीं है - इसलिए नहीं;
• गतिशील जुड़नार उत्पन्न करने के लिए कई पुस्तकालय हैं: एक , दो , तीन । उन्हें जीवन का अधिकार है, लेकिन हमारा होटल एक जटिल इकाई है, इसलिए कोई स्वचालित पीढ़ी नहीं है।

मौजूदा कोड का उपयोग करें!

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

एक बार फिर, होटल एक जटिल इकाई हैं, और मैं सभी कनेक्टेड ऑब्जेक्ट नहीं बनाना चाहता था, और फिर इस सभी अर्थव्यवस्था का समर्थन करता हूं। इसके अलावा, आयात का एक कामकाजी, परीक्षण किया हुआ कोड है, जिसका काम सिर्फ होटल बनाना है, यह भी जुड़ा हुआ है। कम कोड का मतलब है कम त्रुटियाँ।

हम नाक के साथ परीक्षण चलाते हैं, सामान्य तौर पर यह प्लगइन समर्थन के साथ परीक्षण चलाने के लिए एक बहुत अच्छा उपकरण है।

नतीजतन, हमें अपना स्वयं का धावक और कई प्लगइन्स मिले जो कई समस्याओं को हल करते हैं:

• आधार बनाने के लिए स्वतंत्र कदम;

• आधार (लेनदेन या परीक्षण के लिए एक अनूठा आधार) को रीसेट करने के लिए एक आवरण;

• लेनदेन मोड में परीक्षण के बाद डेटाबेस की स्थिति की निगरानी करना;

• बाहरी दुनिया से अलगाव (बाहरी http अनुरोध गीला होना चाहिए);

कमांड लाइन मापदंडों के आधार पर एक डेटाबेस बनाने की एक प्रक्रिया है:

... --with-reuse-db #   ,     --create-db #       ... 

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

हमारे साथ प्रारंभिक आधार बनाने की प्रक्रिया जीआईएस और होटल आयात करते समय पहले से ही एक मिनट तक का समय ले सकती है। इसके अलावा, हम दो प्रारंभिक ठिकानों को बनाए रखते हैं: होटल के साथ और बिना, क्योंकि आयात का परीक्षण करते समय, हमें होटलों की आवश्यकता नहीं है। विशिष्ट TestCase हम आधार टेम्पलेट सेट करते हैं जिसकी हमें आवश्यकता होती है।

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

परीक्षणों को तेज करने के लिए ( flush बारे में), हमने एक अद्वितीय डेटाबेस का उपयोग किया, जो टेम्पलेट के अनुसार बनाया गया था, पोस्टग्रैड्स यह कर सकते हैं:

 src = self.db_conf['TEST_NAME'] new = '{0}_{1}'.format(src, uuid.uuid4().hex) psql( 'DROP DATABASE IF EXISTS "{0}";' 'CREATE DATABASE "{0}" WITH TEMPLATE "{1}";' .format(new, src) ) 

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

परीक्षण के आधार को गति देने के लिए, आप इसे postgresql.conf में भी डाल सकते हैं:

 fsync = off # turns forced synchronization on or off 

वृद्धि भी महसूस की जाती है। वैसे, SSD ड्राइव भी अच्छे हैं :)।

ऐसे परीक्षणों को विधानसभा प्रक्रिया में शामिल करना आसान है, वे जल्दी से पर्याप्त (3-4 मिनट ~ 250 परीक्षण) पास करते हैं और रिलीज में ज्यादा देरी नहीं करते हैं, वे कोड के बगल में हैं। परीक्षणों की क्रियान्विति को गति देने के लिए निगरानी करना और उपाय करना आवश्यक है, जैसा कि परीक्षणों की संख्या केवल बढ़ेगी, जिसका अर्थ है कि उनके निष्पादन का समय।

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

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

हमारे पास क्या है?

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

टेस्ट पहले से ही हमारी मदद करते हैं:

• रिलीज बिल्ड स्टेज पर कुछ कीड़े पकड़ें;

• आंशिक रूप से परीक्षणों के कारण 1.3 से 1.4 django से आगे बढ़ना;

• कुछ तर्क को मैन्युअल रूप से जांचना मुश्किल है, लेकिन परीक्षणों में नहीं (हमारे होटल आयात पर लागू होता है);

• परीक्षणों के साथ यह थोड़ा अधिक आश्वस्त हो गया।

सिद्धांत रूप में, एक शुरुआत की गई है, निर्णय किए गए हैं, आगे क्या होगा - समय बताएगा।

पीएस अजगर और पोस्टग्रेज महान उपकरण हैं - उपयोग।

पोस्ट करनेवाले: naspeh