🔎 👼 🥩 कैचर के साथ माइक्रोसर्विस की एंड-टू-एंड टेस्टिंग 🕵🏻 💟 👩🏻‍🚀

शुभ दोपहर मैं माइक्रोसर्विस - कैचर की एंड-टू-एंड टेस्टिंग के लिए एक नया टूल लाना चाहूंगा
लोगो

परीक्षण क्यों?

मुझे ई 2 ई परीक्षण की आवश्यकता क्यों है? मार्टिन फाउलर सरल परीक्षणों के पक्ष में इसे टालने की सलाह देते हैं ।

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

इसके अलावा, यहां तक कि सभी माइक्रोसर्विसेज का एक पूर्ण परीक्षण कवरेज उनके सही इंटरैक्शन की गारंटी नहीं देता है। डेवलपर्स प्रोटोकॉल (नाम / डेटा प्रकार में त्रुटियां) को गलत तरीके से लागू कर सकते हैं।

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

और इसमें शामिल प्रत्येक सेवाओं के परीक्षण हरे रंग के होंगे।

स्वचालित परीक्षण क्यों?

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

यह कैसे देखा (सामान्य प्रक्रिया):

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

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

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

दूसरे, काफ्का का उपयोग स्थायी डेटा भंडारण के लिए किया गया था। यानी यदि डेटाबेस में जानकारी हटा दी जाती है / बदल जाती है, तो भी सेवा इसे रिबूट पर वापस पढ़ लेगी।

नए परीक्षण उपयोगकर्ता का पंजीकरण कैसा दिखता था (लगभग):

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

सुपर, उपयोगकर्ता पंजीकृत है! अब मरहम में थोड़ा उड़ना: कुछ परीक्षणों में 1 से अधिक परीक्षण उपयोगकर्ता की आवश्यकता होती है। और कभी-कभी परीक्षण पहली बार विफल होते हैं।

और व्यवसाय टीम से नई कार्यक्षमता और पुष्टि का सत्यापन कैसे किया जाता है?
सभी को निम्न पर्यावरण पर दोहराया जाना चाहिए।

कहने की जरूरत नहीं है, थोड़ी देर के बाद आपको एक बंदर की तरह महसूस करना शुरू होता है, जो केवल वही करता है जो उपयोगकर्ताओं को पंजीकृत करता है।

कुछ अन्य डेवलपर्स (आमतौर पर सामने के छोर) को काफ्का से कनेक्ट करने में समस्याएं थीं। और 80+ अक्षरों की एक स्ट्रिंग के साथ टर्मिनल में एक बग के साथ (हर कोई tmux के बारे में नहीं जानता था)।

पेशेवरों :

कुछ भी कॉन्फ़िगर / लिखने की आवश्यकता नहीं है। सीधे चल रहे वातावरण पर परीक्षण करें।
उच्च योग्यता की आवश्यकता नहीं है (सस्ता विशेषज्ञ इसे कर सकते हैं)

विपक्ष :

बहुत समय लगता है (आगे, अधिक)
आमतौर पर केवल नई कार्यक्षमता का परीक्षण किया जाता है (यह स्पष्ट नहीं है कि मौजूदा एक टूट गया है)
अक्सर, कुशल डेवलपर्स मैन्युअल परीक्षण में लगे होते हैं (महंगे विशेषज्ञ सस्ते काम करते हैं)।

स्वचालित कैसे करें?

यदि आप इसे पढ़कर अपना सिर हिलाते हैं और कहते हैं: "हाँ, यह एक बहुत अच्छी प्रक्रिया है, लोग जानते हैं कि वे क्या कर रहे हैं," तो आपको कोई दिलचस्पी नहीं होगी।

घर का बना e2e परीक्षण दो प्रकारों में आते हैं और इस बात पर निर्भर करते हैं कि कौन से प्रोग्रामर स्वतंत्र थे:

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

जो अच्छा लगे। कोई समस्या?

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

पेशेवरों :

स्वचालन

विपक्ष :

डेवलपर्स की योग्यता के लिए अतिरिक्त आवश्यकताएं संभव हैं (यदि वे जावा में विकसित हो रहे हैं, और परीक्षण पायथन में लिखे गए थे)
लिखित कोड का परीक्षण करने के लिए कोड लिखना (परीक्षण का परीक्षण कौन करेगा?)

क्या कुछ तैयार है?

बेशक, सिर्फ बीडीडी की दिशा में देखें। एक ककड़ी है , एक गेज है ।

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

कदम के कार्यान्वयन के साथ स्क्रिप्ट भी एक अलग परियोजना में हैं और तृतीय-पक्ष उत्पादों (ककड़ी / गेज / ...) द्वारा संचालित हैं।

स्क्रिप्ट इस प्रकार है:

Customer sign-up ================ * Go to sign up page Customer sign-up ---------------- tags: sign-up, customer * Sign up a new customer with name "John" email "jdoe@test.de" and "password" * Check if the sign up was successful

और कार्यान्वयन:

 @Step("Sign up as <customer> with email <test@example.com> and <password>") public void signUp(String customer, String email, String password) { WebDriver webDriver = Driver.webDriver; WebElement form = webDriver.findElement(By.id("new_user")); form.findElement(By.name("user[username]")).sendKeys(customer); form.findElement(By.name("user[email]")).sendKeys(email); form.findElement(By.name("user[password]")).sendKeys(password); form.findElement(By.name("user[password_confirmation]")).sendKeys(password); form.findElement(By.name("commit")).click(); } @Step("Check if the sign up was successful") public void checkSignUpSuccessful() { WebDriver webDriver = Driver.webDriver; WebElement message = webDriver.findElements(By.className("message")); assertThat(message.getText(), is("You have been signed up successfully!")); }

पूर्ण परियोजना यहाँ

पेशेवरों :

व्यापार तर्क को मानव-पठनीय भाषा में वर्णित किया गया है और एक स्थान पर संग्रहीत किया गया है (इसका उपयोग प्रलेखन के रूप में किया जा सकता है)
तैयार समाधान का उपयोग किया जाता है, डेवलपर्स को केवल यह जानना होगा कि उनका उपयोग कैसे किया जाए

विपक्ष :

प्रबंधक स्क्रिप्ट नहीं पढ़ेंगे और लिखेंगे
आपको विनिर्देशों और उनके कार्यान्वयन दोनों का पालन करना होगा (और यह कोड और संपादन विनिर्देशों को लिखना है)

अच्छा, फिर कैचर क्यों?

बेशक, प्रक्रिया को सरल बनाने के लिए।

डेवलपर केवल json / yaml में स्क्रिप्ट लिखता है, और पकड़ने वाला उन्हें निष्पादित करता है। स्क्रिप्ट में क्रमिक रूप से निष्पादित कदम होते हैं, उदाहरण के लिए:

 steps: - http: post: url: '127.0.0.1/save_data' body: {key: '1', data: 'foo'} - postgres: request: conf: 'dbname=test user=test host=localhost password=test' query: 'select * from test where id=1'

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

 variables: bonus: 5000 initial_value: 1000 steps: - http: post: url: '{{ user_service }}/sign_up' body: {username: 'test_user_{{ RANDOM_INT }}', data: 'stub'} register: {user_id: '{{ OUTPUT.uuid }}' - kafka: consume: server: '{{ kafka }}' topic: '{{ new_users_topic }}' where: equals: {the: '{{ MESSAGE.uuid }}', is: '{{ user_id }}'} register: {balance: '{{ OUTPUT.initial_balance }}'}

इसके अतिरिक्त, आप परीक्षण चरण चला सकते हैं:

 - check: # check user's initial balance equals: {the: '{{ balance }}', is: '{{ initial_value + bonus }}'}

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

 include: file: register_user.yaml as: sign_up steps: # .... some steps - run: include: sign_up # .... some steps

स्क्रिप्ट डालने और उपयोग करने से संसाधन के इंतजार की समस्या हल हो सकती है (सेवा शुरू होने तक प्रतीक्षा करें)।

रेडी-मेड बिल्ट-इन स्टेप्स और एक अतिरिक्त रिपॉजिटरी के अलावा, अपने मॉड्यूल को पायथन में लिखना संभव है (सिर्फ एक्सटर्नलस्ट से विरासत में) या किसी अन्य भाषा में:

 #!/bin/bash one=$(echo ${1} | jq -r '.add.the') two=$(echo ${1} | jq -r '.add.to') echo $((${one} + ${two}))

और उपयोग करें:

 --- variables: one: 1 two: 2 steps: - math: add: {the: '{{ one }}', to: '{{ two }}'} register: {sum: '{{ OUTPUT }}'}

लिपियों को डॉक फ़ाइल में रखा जाता है और सीआई के माध्यम से चलाया जाता है।

साथ ही मौजूदा परिवेश का परीक्षण करने के लिए इस छवि का उपयोग मैराथन / K8s में किया जा सकता है। फिलहाल मैं एक बैकेंड (AnsibleTower के समान) पर काम कर रहा हूं ताकि परीक्षण प्रक्रिया को और भी आसान और सुविधाजनक बनाया जा सके।

पेशेवरों :

कोड लिखने की आवश्यकता नहीं है (केवल कस्टम मॉड्यूल के मामले में)
इन्वेंट्री फ़ाइलों के माध्यम से वातावरण स्विच करना (पहनावा में)
आप अपने स्वयं के मॉड्यूल का उपयोग कर सकते हैं (किसी भी भाषा में, यहां तक कि श)

विपक्ष :

गैर-मानव-पठनीय वाक्यविन्यास (BDD टूल की तुलना में)

एक निष्कर्ष के बजाय

जब मैंने इस उपकरण को लिखा था, तो मैं सिर्फ उस समय को कम करना चाहता था जो मैं आमतौर पर परीक्षणों पर खर्च करता हूं। ऐसा हुआ कि प्रत्येक नई कंपनी को ऐसी प्रणाली लिखना (या फिर से लिखना) करना पड़ता है।

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

upd

जैसा कि मुझे टिप्पणियों में संकेत दिया गया था, विषय का खुलासा नहीं किया गया है।
मैं यहां सबसे विवादास्पद शोधों को इंगित करने का प्रयास करूंगा।

एंड-टू-एंड परीक्षण इकाई परीक्षण नहीं हैं। मैंने पहले ही इस लेख में एम। फाउलर का उल्लेख किया है। इकाई परीक्षण परीक्षण बैकेंड परियोजना (मानक tests निर्देशिका) में हैं और हर बार सीआई में कोड परिवर्तन को चलाते हैं। और e2e परीक्षण एक अलग परियोजना है, वे आमतौर पर अधिक समय लेते हैं, सभी भाग लेने वाली सेवाओं की बातचीत का परीक्षण करते हैं और आपकी परियोजना के कोड (ब्लैक बॉक्स) के बारे में कुछ भी नहीं जानते हैं।
आपको एकीकरण (और नीचे) परीक्षणों के लिए कैचर का उपयोग नहीं करना चाहिए। यह महंगा है। वर्तमान बैकएंड के लिए अपने YP पर परीक्षण लिखना बहुत तेज़ है। यदि आपके व्यावसायिक तर्क 2 या अधिक सेवाओं में फैले हैं, तो आपको एंड-टू-एंड परीक्षणों की आवश्यकता है।
कैचर भी एक बीडीडी है। मेरे दृष्टिकोण से, गेज / ककड़ी पर मुख्य लाभ तैयार किए गए मॉड्यूल और उन्हें जोड़ने में आसानी है। आदर्श रूप में, केवल एक परीक्षा लिखी जाती है। अंतिम कंपनी में, मैंने मानक घटकों पर सभी 4 परीक्षण लिखे, बिना कुछ भी प्रोग्रामिंग किए। तदनुसार, योग्यता की आवश्यकताएं (और ऐसे विशेषज्ञ की कीमत) कम होगी। केवल json / yaml के ज्ञान और विनिर्देशों को पढ़ने की क्षमता की आवश्यकता है।
कैचर टेस्ट लिखने के लिए, आपको कैचर-डीएसएल सीखना होगा। काश, यह सच है। पहले मैं माइक्रोफ़ोन से सही, खुद को लिखने के लिए परीक्षण करना चाहता था। लेकिन फिर मैंने सोचा कि वे तब मुझे अनावश्यक रूप से आग लगा देंगे;) जैसा कि ऊपर बताया गया है - कैचर डीएसएल मानक जोंस / याम्ल और स्टेप स्पेसिफिकेशन्स है। कुछ भी नया नहीं है।
आप मानक प्रौद्योगिकियों का उपयोग कर सकते हैं और अपनी खुद की कुछ लिख सकते हैं। हालाँकि, हम माइक्रोसेवा के बारे में बात कर रहे हैं। यह बड़ी संख्या में विभिन्न तकनीकों और परमाणु हथियारों और बड़ी संख्या में टीम है। और अगर जावा कमांड के लिए junit + testcontainers स्पष्ट पसंद है, तो erlang टीम कुछ और चुनेगी। शीर्ष पर 30+ टीमों के साथ एक बड़ी कंपनी में, वे तय करेंगे कि सभी परीक्षण नए बुनियादी ढांचे / क्यूए टीम को प्रस्तुत किए जाएं। क्या आप सोच सकते हैं कि वे इस चिड़ियाघर में कितने खुश हैं?
यदि आपके पास 4-5 ई 2 ई परीक्षण हैं, तो आप किसी भी स्क्रिप्टिंग भाषा में सब कुछ लिख सकते हैं और इसके बारे में भूल सकते हैं। हालांकि, यदि तर्क समय के साथ बदलता है, तो 2-4 वर्षों के बाद आपको सीधे परीक्षण के व्यावसायिक तर्क को वितरित करना और परीक्षण किए गए घटकों तक पहुंच के तरीकों को लागू करना होगा। इसलिए अंत में आप अपने कैचर को लिखते हैं, बस इतना लचीला नहीं। इसे समझने में मुझे 4 कार्यान्वयन लगे;)

कैचर के साथ माइक्रोसर्विस की एंड-टू-एंड टेस्टिंग

परीक्षण क्यों?

स्वचालित परीक्षण क्यों?

स्वचालित कैसे करें?

क्या कुछ तैयार है?

अच्छा, फिर कैचर क्यों?

एक निष्कर्ष के बजाय

upd

More articles: