जावा बैकएंड टेस्टिंग प्रैक्टिस + रेस्ट-एश्योर्ड

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

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


(पैरोडी के रूप में इस्तेमाल की गई छवि)

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

क्यों आराम का आश्वासन दिया?

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

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

विचारों की तलाश में, मैंने अपनी विकास टीम के साथ-साथ परीक्षण से जुड़े सहयोगियों की ओर रुख किया और सीटीओ ने मुझे रेस्ट-एश्योर्ड ( rest-assured.io ) देखने की सलाह दी। जब मैंने खुले स्रोतों में प्रलेखन और नमूना परीक्षण पढ़ा, तो रेस्ट-एश्योर्ड द्वारा प्रस्तावित दृष्टिकोण मुझे बहुत आकर्षक लगा। इसका मतलब JSON के रूप में बैकएंड से एक प्रतिक्रिया प्राप्त करना है, जिसे हम अच्छे पुराने जावा ऑब्जेक्ट्स में शामिल करते हैं।

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

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

पंख परीक्षण

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

लड़ाई के लिए!

परियोजना शुरू हुई, और जब पहली प्रतिक्रिया संरचनाओं का वर्णन किया गया, तो परीक्षण प्रलेखन की तैयारी और ऑटोटेस्ट्स का लेखन शुरू हुआ। बड़ी तस्वीर को समझने के लिए, मैं ऑटोटेस्ट का पूरा ढेर दूंगा:

• जावा,
• JUnit4 - परीक्षण लिपियों का निष्पादन और मानकीकरण (मानक एनोटेशन @Parametrize),
  
• बाकी का आश्वासन दिया - निर्माण और प्रश्नों को क्रियान्वित,
• AssertJ - प्राप्त मूल्यों का सत्यापन,
• लुभाना - रिपोर्टिंग भवन,
• पद - सभा
• जैक्सन - deserialization।

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



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



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



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

सामान्य तौर पर, मुझे दृष्टिकोण पसंद आया। यह उत्सुक है कि कुछ समय बाद इसे दूसरे ग्राहक की परियोजना पर लागू किया जाना शुरू हुआ (हालांकि हमारी आपूर्ति से नहीं)। और हमने ऑटोमेशन टेस्टिंग APIs (JUnit + AssertJ + Rest-Assured) के लिए असेंबल किए गए स्टैक को Java / Kotlin प्रोजेक्ट्स के लिए प्रमुख की श्रेणी में रखा। पायथन में, इसे खींचना प्रतिवाद होगा, क्योंकि यह बेहतर है कि विकास और परीक्षण क्षमता ओवरलैप हो।

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

परिणाम

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

लेख लेखक: दिमित्री मास्टर्स

पुनश्च हमने अपने लेख रनेट की कई साइटों पर प्रकाशित किए हैं। वीके , एफबी या टेलीग्राम-चैनल पर हमारे सभी प्रकाशनों और अन्य मैक्सिलैक्ट समाचारों के बारे में जानने के लिए हमारे पेज की सदस्यता लें।