PHP बैकएंड के लिए कोडप्शन टेस्ट

सभी को नमस्कार! मेरा नाम पाशा है और मैं लमोडा में ऑर्डर प्रोसेसिंग टीम के लिए एक QA इंजीनियर हूं। मैंने हाल ही में PHP Badoo मीटअप में बात की थी। आज मैं अपनी रिपोर्ट की एक प्रतिलिपि प्रदान करना चाहता हूं।

हम कोडेप्शन के बारे में बात करेंगे, कि हम लमोडा में इसका उपयोग कैसे करते हैं और इस पर परीक्षण कैसे लिखें।



लमोडा में कई सेवाएं हैं। क्लाइंट सेवाएं हैं जो हमारे उपयोगकर्ताओं के साथ सीधे संपर्क करती हैं, साइट के उपयोगकर्ताओं के साथ, मोबाइल एप्लिकेशन। हम उनके बारे में बात नहीं करेंगे। और वहाँ है जो हमारी कंपनी गहरी बैकेंड कहती है - ये हमारे बैक-ऑफिस सिस्टम हैं जो हमारी व्यावसायिक प्रक्रियाओं को स्वचालित करते हैं। इनमें डिलीवरी, स्टोरेज, फोटो स्टूडियो का स्वचालन और एक कॉल सेंटर शामिल हैं। इन सेवाओं में से अधिकांश PHP में विकसित की जाती हैं।

हमारे स्टैक के बारे में संक्षेप में बोलते हुए, यह PHP + सिम्फनी है। यहां और Zend'e पर पुराने प्रोजेक्ट हैं। PostgreSQL और MySQL को डेटाबेस के रूप में उपयोग किया जाता है, और रैबिट या काफ्का को मैसेजिंग सिस्टम के रूप में उपयोग किया जाता है।

PHP का समर्थन क्यों?

क्योंकि उनके पास आम तौर पर एक शाखा एपीआई होता है - यह या तो आरईएसटी है, कुछ जगहों पर थोड़ा सा सोप है। यदि उनके पास UI है, तो यह UI एक सहायक है, जिसे हमारे आंतरिक उपयोगकर्ता उपयोग करते हैं।

लमोडा में हमें ऑटोटेस्ट की आवश्यकता क्यों है?

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

हमें ऑटोटेस्ट की आवश्यकता क्यों है?

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

ठीक है, इस बारे में बात की कि हमें ऑटोटेस्ट की आवश्यकता क्यों है। अब बात करते हैं कि लमोडा में हम कौन से परीक्षण लिखते हैं।



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

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

आगे बढ़ो, E2E परीक्षण। मैंने उन्हें 2 भागों में विभाजित किया। हमारे पास परीक्षण हैं जो UI और बैकएंड के एक गुच्छा का परीक्षण करते हैं। और ऐसे परीक्षण हैं जिन्हें हम प्रवाह परीक्षण कहते हैं। वे श्रृंखला का परीक्षण करते हैं - किसी वस्तु का जीवन शुरू से अंत तक।

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

चूंकि हमारे पास यह यूआई आंतरिक उपयोगकर्ताओं द्वारा उपयोग किया जाता है, इसलिए क्रॉस-ब्राउज़र का उपयोग हमारे लिए महत्वपूर्ण नहीं है। हम किसी भी फार्म पर इन परीक्षणों को नहीं चलाते हैं, यह हमारे लिए एक ब्राउज़र में जाँच करने के लिए पर्याप्त है, और कभी-कभी हमें ब्राउज़र का उपयोग करने की आवश्यकता भी नहीं होती है।

"हमने टेस्ट ऑटोमेशन के लिए कोडसेप्शन क्यों चुना?" - आप शायद पूछें।

सच कहूं तो मेरे पास इस सवाल का कोई जवाब नहीं है। जब मैं लमोडा आया, तो ऑटोटैस्ट लिखने के लिए पहले से ही कोडैसेशन को मानक के रूप में चुना गया था, और मैं वास्तव में इसके पार आया था। लेकिन कुछ समय के लिए इस ढांचे के साथ काम करने के बाद, मुझे अभी भी समझ में आया कि क्यों कोडेशन। यह मैं आपके साथ साझा करना चाहता हूं।

क्यों होती है धारणा?

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

मैं संक्षेप में कहूंगा कि कोडसेप्शन कैसा है, क्योंकि कई लोगों ने इसके साथ काम किया है।



एक अभिनेता मॉडल पर संहिता काम करती है। जब आप इसे प्रोजेक्ट में खींचते हैं और आरंभ करते हैं, तो ऐसी संरचना उत्पन्न होती है।

हमारे पास yml फाइलें हैं, यहां नीचे दिए गए हैं - functional.suite.yml , एकीकरण . मुकदमा .yml, unit.suite.yml । वे आपके परीक्षणों का विन्यास बनाते हैं। प्रत्येक प्रकार के परीक्षण के लिए डैडीज हैं, जहां ये परीक्षण हैं, 3 सहायक डैडीज हैं:

_ डेटा - परीक्षण डेटा के लिए;
_ आउटपुट - जहां रिपोर्ट रखी गई हैं (xml, html);
_ समर्थन - जहां कुछ सहायक सहायकों, कार्यों और आपके द्वारा लिखी गई हर चीज को आपके परीक्षणों में उपयोग करने के लिए रखा जाता है।

शुरू करने के लिए, मैं आपको बताऊंगा कि हमने कोडसेप्शन से क्या लिया और इसे बॉक्स से बाहर कर दिया, कुछ भी संशोधित नहीं किया, अतिरिक्त कार्यों या समस्याओं को हल नहीं किया।

मानक मॉड्यूल

1. PhpBrowser
2. बाकी
3. Db
4. CLI
5. AMQP

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

दूसरा मॉड्यूल जिसका हम उपयोग करते हैं वह है REST। मुझे लगता है कि नाम स्पष्ट करता है कि वह क्या कर रहा है। किसी भी http इंटरैक्शन के लिए, आप इस मॉड्यूल का उपयोग कर सकते हैं। यह मुझे लगता है कि लगभग सभी इंटरैक्शन इसमें हल किए गए हैं: हेडर, कुकीज़, प्राधिकरण। आपकी जरूरत की हर चीज इसमें है।

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

Cli मॉड्यूल, जो आपको परीक्षणों से शेल और बैश कमांड चलाने की अनुमति देता है, और हम इसका उपयोग भी करते हैं।

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

वास्तव में, संहिता, कम से कम हमारे मामले में, हमारे द्वारा आवश्यक सभी कार्यों का 80-85% कवर करती है। लेकिन मुझे अभी भी कुछ काम करना था।

चलो SOAP से शुरू करते हैं।


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


उदाहरण के लिए, हमारे पास मोनोलिथ है जिसमें कई WSDL, कई SOAP एंडपॉइंट हैं। इसका मतलब यह है कि इसे एक yml फ़ाइल में कॉन्फ़िगर करने के लिए कोडप्शन मॉड्यूल में यह असंभव है ताकि यह कई के साथ काम कर सके।


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


कोडेसेप्शन में, काफ्का के साथ कोई काम नहीं है और काफ्का के साथ काम करने के लिए अधिक या कम आधिकारिक ऐड-ऑन नहीं हैं। चिंता की कोई बात नहीं है, हमने अपना मॉड्यूल लिखा है।


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


निष्कर्ष : कोडप्शन के लिए मॉड्यूल लिखना आसान है।

आगे बढ़ो। जैसा कि मैंने कहा, Codeception में एक Cli मॉड्यूल होता है - शेल कमांड के लिए एक आवरण और उनके आउटपुट के साथ काम करना।


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

तो हमें परीक्षणों में शेल चलाने की आवश्यकता क्यों है?

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

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

किसी एप्लिकेशन में शेल कैसे चलाएं?

पहला: परीक्षण उसी स्थान पर चलाएं जहां आवेदन स्थित है। चूंकि हमारे पास डॉकटर के सभी एप्लिकेशन हैं, इसलिए परीक्षण उसी कंटेनर में चलाए जा सकते हैं जहां सेवा स्वयं स्थित है।

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


एक और समस्या जो हमें परीक्षणों में मिली, वह विभिन्न फाइल सिस्टमों के साथ काम कर रही है। नीचे एक उदाहरण है कि आप क्या कर सकते हैं और इसके साथ काम करना चाहिए। पहले तीन हमारे लिए प्रासंगिक हैं। ये Webdav, SFTP और Amazon फ़ाइल सिस्टम हैं।

आपको किसके साथ काम करने की आवश्यकता है?

1. WebDAV
2. एफ़टीपी / एसएफटीपी
3. एडब्ल्यूएस एस 3
4. स्थानीय
5. एज़्योर, ड्रॉपबॉक्स, गूगल ड्राइव

यदि आप कोडेप्शन के माध्यम से अफवाह करते हैं, तो आप लगभग किसी भी अधिक या कम लोकप्रिय फ़ाइल सिस्टम के लिए कुछ मॉड्यूल पा सकते हैं।



केवल एक चीज जो मुझे नहीं मिली, वह वेबदव के लिए है। लेकिन ये फ़ाइल सिस्टम, प्लस या माइनस, उनके साथ बाहरी काम के संदर्भ में समान हैं, और हम उनके साथ उसी तरह काम करना चाहते हैं।

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


फ़ाइलों की एक सूची प्राप्त करें, निर्देशिका को साफ़ करें, एक फ़ाइल लिखें, और इसी तरह। अगर आप वहां अमेजन फाइल सिस्टम भी जोड़ते हैं, तो हमारी जरूरतें पूरी हो जाएंगी।

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


मैं यहाँ क्या मुख्य कार्य देख रहा हूँ:

1. वांछित संरचना के डेटाबेस को कैसे रोल करें - डीबी
2. डेटाबेस को टेस्ट डेटा के साथ कैसे भरें - डीबी, फिक्स्चर
3. चयन और जांच कैसे करें - डीबी

संहिता में सभी 3 कार्यों के लिए, 2 मॉड्यूल हैं - डीबी, जिसके बारे में मैंने पहले ही बात की थी, दूसरे को फिक्स्चर कहा जाता है।

इन 2 मॉड्यूल और 3 कार्यों में से, हम तीसरे कार्य के लिए केवल DB का उपयोग करते हैं।

पहले कार्य के लिए, आप डीबी का उपयोग कर सकते हैं। वहां आप SQL डंप को कॉन्फ़िगर कर सकते हैं जिसमें से डेटाबेस को तैनात किया जाएगा, ठीक है, जुड़नार के साथ मॉड्यूल, मुझे लगता है कि यह स्पष्ट है कि इसकी आवश्यकता क्यों है।

एरे के रूप में जुड़नार होंगे जो डेटाबेस में बने रह सकते हैं।

जैसा कि मैंने कहा, पहले 2 कार्य हम कुछ अलग तरीके से हल करते हैं, अब मैं आपको बताऊंगा कि हम इसे कैसे करते हैं।

डेटाबेस परिनियोजन

1. PostgreSQL या MySQL के साथ एक कंटेनर उठाना
2. हम सभी प्रवासों को सिद्धांत पलायन के साथ जोड़ते हैं

पहला एक डेटाबेस को तैनात करने के बारे में है। परीक्षणों में यह कैसे होता है। हम कंटेनर को वांछित डेटाबेस के साथ बढ़ाते हैं - या तो PostgreSQL या MySQL, फिर डॉक्ट्रिन माइग्रेशन का उपयोग करके सभी आवश्यक माइग्रेशन रोल करें। सब कुछ, वांछित संरचना का डेटाबेस तैयार है, इसका उपयोग परीक्षणों में किया जा सकता है।

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

दूसरा बिंदु परीक्षण डेटा का निर्माण है। हम Codeception से जुड़नार मॉड्यूल का उपयोग नहीं करते हैं, हम जुड़नार के लिए सिम्फनी बंडल का उपयोग करते हैं।


इसका एक लिंक है और एक उदाहरण है कि आप डेटाबेस में जुड़नार कैसे बना सकते हैं।

आपकी स्थिरता तब डोमेन के कुछ ऑब्जेक्ट के रूप में बनाई जाएगी, इसे डेटाबेस में संग्रहीत किया जा सकता है, और परीक्षण डेटा तैयार हो जाएगा।

DoctrineFixtureBundle क्यों?

1. संबंधित वस्तुओं की श्रृंखला बनाने में आसान।
2. विभिन्न परीक्षणों के लिए जुड़नार समान होने पर कम डेटा दोहराव।
3. डेटाबेस की संरचना को बदलते समय कम संपादन।
4. फ़िक्चर क्लासेस सरणियों की तुलना में बहुत अधिक दृश्य हैं।

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

हमने डेटाबेस के बारे में बात की है, चलो मोकी के बारे में थोड़ी बात करते हैं।

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

मोक के नियम

1. सभी बाहरी http- सेवा इंटरैक्शन को रोएं
2. न केवल सकारात्मक, बल्कि नकारात्मक परिदृश्य भी जांचना

इंटरैक्शन कुछ REST या SOAP http इंटरैक्शन हैं। परीक्षणों के ढांचे के भीतर ये सभी इंटरैक्शन हम गीला कर रहे हैं। यही है, हमारे परीक्षणों में कहीं भी बाहरी प्रणालियों के लिए कोई वास्तविक अपील नहीं है। यह परीक्षणों को स्थिर बनाता है। क्योंकि एक बाहरी सेवा काम कर सकती है, काम नहीं कर सकती है, धीरे-धीरे प्रतिक्रिया दे सकती है, जल्दी से, सामान्य रूप से, यह नहीं जान सकती कि इसका व्यवहार क्या है। इसलिए, हम इसे मोक के साथ कवर करते हैं।

हमारा भी ऐसा नियम है। हम न केवल सकारात्मक बातचीत को गीला कर रहे हैं, बल्कि कुछ नकारात्मक मामलों की जांच करने की भी कोशिश कर रहे हैं। उदाहरण के लिए, जब कोई तृतीय-पक्ष सेवा 500 वीं त्रुटि के साथ प्रतिक्रिया करती है या कुछ और सार्थक त्रुटि उत्पन्न करती है, तो हम यह सब जाँचने का प्रयास करते हैं।

हम मॉक के लिए वायरमॉक का उपयोग करते हैं, कोडैसे ही समर्थन करता है ..., इसमें इस तरह का एक आधिकारिक ऐड-ऑन हेटमॉक है, लेकिन हमें वायरमॉक अधिक पसंद आया। यह कैसे काम करता है?



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



वायरमॉक, यदि आप स्लाइड को देखते हैं - ऐसा एक बॉक्स है, रिक्वेस्ट मैपिंग, इसमें ऐसे मैपिंग का एक सेट है जो कहता है कि यदि ऐसा अनुरोध आता है, तो आपको इस तरह का जवाब देने की आवश्यकता है। सब कुछ बहुत सरल है: एक अनुरोध आया - एक नकली प्राप्त हुआ।

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

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



इस तथ्य के अलावा कि यह मॉक बनाया जा सकता है, वायरमॉक के पास बाद में यह जांचने का अवसर है कि इस मॉक में क्या अनुरोध किया गया था। परीक्षणों में भी यह बहुत उपयोगी है।

खुद के बारे में, शायद सब कुछ, और कुछ शब्द हमारे परीक्षणों को कैसे चलाया जाता है, और थोड़े बुनियादी ढांचे के बारे में।

हम क्या उपयोग कर रहे हैं?



ठीक है, सबसे पहले, हमारे पास डॉकटर में सभी सेवाएं हैं, इसलिए एक परीक्षण वातावरण लॉन्च करना सही कंटेनरों को बढ़ा रहा है।

Make, CI Bamboo.

CI?



, — , , , Kafka, Rabbit, .

Docker Compose. CI, Kubernetes. .

?

, , , — 5-10 , — 6 30 .



, .

. ? , , . , .

2 . , , unit, unit-. - , .

, . .

- — , , Codeception, . , .