REST एश्योर्ड: टूल का उपयोग करने के पाँच वर्षों से हमने जो सीखा है

REST एश्योर्ड - REST सेवाओं के परीक्षण के लिए DSL, जो जावा परीक्षण में एम्बेडेड है। यह समाधान नौ साल पहले दिखाई दिया था और अपनी सादगी और सुविधाजनक कार्यक्षमता के कारण लोकप्रिय हो गया है।

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

यह लेख REST एश्योर्ड की ऐसी निहित विशेषताओं के बारे में है। उन्हें इस बात पर ध्यान देने की आवश्यकता है कि अगर कोई मौका है कि परियोजना में परीक्षणों की संख्या तेजी से बढ़ेगी - ताकि आपको बाद में उन्हें फिर से लिखना न पड़े।

हम क्या परीक्षण कर रहे हैं

DINS UCaaS प्लेटफॉर्म के विकास में शामिल है। विशेष रूप से, हम उस एपीआई का विकास और परीक्षण करते हैं जिसका उपयोग रिंगसेंटरियल स्वयं करता है और तीसरे पक्ष के डेवलपर्स को प्रदान करता है ।

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

जब REST एश्योर्ड को फायदा होगा

यदि आपका लक्ष्य संपूर्ण एपीआई का पूरी तरह से परीक्षण करना नहीं है, तो ऐसा करने का सबसे आसान तरीका REST एश्योर्ड है। यह प्रतिक्रिया संरचना, पीवीडी और धुआं परीक्षणों की जांच करने के लिए अच्छी तरह से अनुकूल है।

यह एक साधारण परीक्षण है, जो यह जाँचता है कि समापन बिंदु 200 ओके की स्थिति देता है जब इसे एक्सेस करते हैं:

given() .baseUri("http://cookiemonster.com") .when() .get("/cookies") .then() .assertThat() .statusCode(200); 

given कीवर्ड, when और then अनुरोध बनाते हैं: given निर्धारित करता है कि अनुरोध में क्या भेजा जाएगा, when -किस पद्धति से और किस बिंदु पर हम अनुरोध भेजते हैं, और then प्राप्त प्रतिक्रिया कैसे जांची जाती है। इसके अलावा, आप प्रतिक्रिया बॉडी को JsonPath या XmlPath ऑब्जेक्ट के रूप में निकाल सकते हैं, फिर प्राप्त डेटा का उपयोग कर सकते हैं।

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

इसके लिए, आश्वस्त आश्वासन में हैं:

• RequestSpecification / ResponseSpecification / ResponseSpecification ;
• बुनियादी विन्यास;
• फिल्टर।

अनुरोध और प्रतिक्रिया

ये दो वर्ग आपको अनुरोध पैरामीटर और प्रतिक्रिया से अपेक्षाओं को निर्धारित करने की अनुमति देते हैं:

 RequestSpecification requestSpec = given() .baseUri("http://cookiemonster.com") .header("Language", "en"); requestSpec.when() .get("/cookiesformonster") .then() .statusCode(200); requestSpec.when() .get("/soup") .then() .statusCode(400); 

 ResponseSpecification responseSpec = expect() .statusCode(200); given() .expect() .spec(responseSpec) .when() .get("/hello"); given() .expect() .spec(responseSpec) .when() .get("/goodbye"); 

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

 RequestSpecification requestSpec = given() .baseUri("http://cookiemonster.com") .header("Language", "en"); RequestSpecification yetAnotherRequestSpec = given() .header("Language", "fr"); given() .spec(requestSpec) .spec(yetAnotherRequestSpec) .when() .get("/cookies") .then() .statusCode(200); 

कॉल लॉग:

 Request method: GET Request URI: http://localhost:8080/ Headers: Language=en Language=fr Accept=*/* Cookies: <none> Multiparts: <none> Body: <none> java.net.ConnectException: Connection refused (Connection refused) 

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

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

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

बेसिक रेस्ट एश्योर्ड कॉन्फ़िगरेशन

REST एश्योर्ड में प्रश्नों को टेम्पलेट करने का दूसरा तरीका बुनियादी कॉन्फ़िगरेशन को कॉन्फ़िगर करना और RestAssured क्लास के स्थिर क्षेत्रों को परिभाषित करना है:

 @BeforeMethod public void configureRestAssured(...) { RestAssured.baseURI = "http://cookiemonster.com"; RestAssured.requestSpecification = given() .header("Language", "en"); RestAssured.filters(new RequestLoggingFilter(), new ResponseLoggingFilter()); ... } 

हर बार अनुरोध में मान स्वचालित रूप से जुड़ जाएंगे। कॉन्फ़िगरेशन को एनोटेशन @BeforeMethod in TestNG और @BeforeEach साथ JUnit में @BeforeEach गया है - इसलिए आप सुनिश्चित कर सकते हैं कि आपके द्वारा चलाया जाने वाला प्रत्येक परीक्षण समान मापदंडों से शुरू होगा।

हालाँकि, कॉन्फ़िगरेशन समस्याओं का एक संभावित स्रोत होगा, क्योंकि यह स्थिर है ।

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

बाकी आश्वासन फिल्टर

निर्दिष्ट अपेक्षाओं के अनुपालन के लिए जाँच करने से पहले फ़िल्टर भेजने और प्रतिक्रिया करने से पहले दोनों अनुरोधों को संशोधित करते हैं। आवेदन उदाहरण - लॉगिंग, या प्राधिकरण जोड़ना:

 public class OAuth2Filter implements AuthFilter { String accessToken; OAuth2Filter(String accessToken) { this.accessToken = accessToken; } @Override public Response filter(FilterableRequestSpecification requestSpec, FilterableResponseSpecification responseSpec, FilterContext ctx) { requestSpec.replaceHeader("Authorization", "Bearer " + accessToken); return ctx.next(requestSpec, responseSpec); } } 

 String accessToken = getAccessToken(username, password); OAuth2Filter auth = new OAuth2Filter(accessToken); given() .filter(auth) .filter(new RequestLoggingFilter()) .filter(new ResponseLoggingFilter()) ... 

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

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

 given() .filter(auth) .filter(new RequestLoggingFilter()) … given() .filter(new RequestLoggingFilter()) .filter(auth) 

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

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

फिल्टर ही नहीं

फ़िल्टर के माध्यम से प्राधिकरण कैसे करना है, ऊपर दिखाया गया है। लेकिन REST एश्योर्ड में इस पद्धति के अलावा, AuthenticationScheme माध्यम से एक और है:

 String accessToken = getAccessToken(username, password); OAuth2Scheme scheme = new OAuth2Scheme(); scheme.setAccessToken(accessToken); RestAssured.authentication = scheme; 

यह एक अप्रचलित विधि है। इसके बजाय, आपको ऊपर दिखाए गए को चुनना चाहिए। इसके दो कारण हैं:

निर्भरता की समस्या

REST एश्योर्ड के लिए प्रलेखन से संकेत मिलता है कि Oauth1 या Oauth2 (क्वेरी पैरामीटर के रूप में एक टोकन निर्दिष्ट करके) का उपयोग करने के लिए, प्राधिकरण को Scribe के आधार पर जोड़ा जाना चाहिए। हालांकि, नवीनतम संस्करण आयात करने से आपको मदद नहीं मिलेगी - आप खुली समस्याओं में से एक में वर्णित त्रुटि का सामना करेंगे। आप इसे केवल लाइब्रेरी के पुराने संस्करण 2.5.3 को आयात करके हल कर सकते हैं। हालाँकि, इस मामले में आप एक और समस्या में आएँगे।

सामान्य तौर पर, Scribe का कोई अन्य संस्करण Oauth2 REST एश्योर्ड संस्करण 3.0.3 और उच्चतर के साथ काम करता है (और हालिया रिलीज़ 4.0.0 ने इसे ठीक नहीं किया)।

लॉगिंग से काम नहीं चलता

एक विशिष्ट क्रम में प्रश्नों को फ़िल्टर लागू किया जाता है। और उनके बाद AuthenticationScheme लगाया जाता है। इसका मतलब यह है कि परीक्षण में प्राधिकरण के साथ एक समस्या का पता लगाना मुश्किल होगा - यह प्रतिज्ञा नहीं है।

REST एश्योर्ड सिंटैक्स के बारे में अधिक

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

 @Test public void shouldCorrectlyCountAddedCookies() { Integer addNumber = 10; JsonPath beforeCookies = given() .when() .get("/latestcookies") .then() .assertThat() .statusCode(200) .extract() .jsonPath(); String beforeId = beforeCookies.getString("id"); JsonPath afterCookies = given() .body(String.format("{number: %s}", addNumber)) .when() .put("/cookies") .then() .assertThat() .statusCode(200) .extract() .jsonPath(); Integer afterNumber = afterCookies.getInt("number"); String afterId = afterCookies.getString("id"); JsonPath history = given() .when() .get("/history") .then() .assertThat() .statusCode(200) .extract() .jsonPath(); assertThat(history.getInt(String.format("records.find{r -> r.id == %s}.number", beforeId))) .isEqualTo(afterNumber - addNumber); assertThat(history.getInt(String.format("records.find{r -> r.id == %s}.number", afterId))) .isEqualTo(afterNumber); } 

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

given() , when() और then() बीस्ट से बीडस्टर्ड, जैसे कि स्पॉक या ककड़ी, लिया जाता है। हालांकि, जटिल परीक्षणों में, उनका अर्थ खो जाता है, क्योंकि परीक्षण का पैमाना एक अनुरोध से बहुत बड़ा हो जाता है - यह एक छोटी सी क्रिया है जिसे एक पंक्ति द्वारा निरूपित करने की आवश्यकता होती है। और इसके लिए, आप REST एश्योर्ड कॉल को सहायक कक्षाओं में स्थानांतरित कर सकते हैं:

 public class CookieMonsterHelper { public static JsonPath getCookies() { return given() .when() .get("/cookiesformonster") .then() .extract() .jsonPath(); } ... } 

और परीक्षण में कॉल करें:

 JsonPath response = CookieMonsterHelper.getCookies(); 

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

निष्कर्ष

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

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

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

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

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