मोबाइल परीक्षण स्वचालन के लिए मॉक सर्वर

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

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



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

विकल्प क्या हैं?

मेरे मामले में मज़ाक करने के दो तरीके थे:

• क्लाउड में या रिमोट मशीन पर एक मॉक सर्वर तैनात करें (यदि हम गोपनीय घटनाक्रमों के बारे में बात कर रहे हैं जिन्हें क्लाउड पर नहीं लिया जा सकता है);
• मॉक सर्वर को स्थानीय रूप से लॉन्च करें - उस फ़ोन पर, जिस पर मोबाइल एप्लिकेशन का परीक्षण किया जा रहा है।

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

एक मॉक सर्वर का चयन

कई अलग-अलग उपकरण हैं। मैंने कई लोगों के साथ काम करने की कोशिश की और लगभग सभी में मैं कुछ समस्याओं में भाग गया:

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

हम काम के सिद्धांत का विश्लेषण करते हैं

Okhttpmockwebserver का वर्तमान संस्करण आपको कई कार्य परिदृश्यों को कार्यान्वित करने की अनुमति देता है:

• उत्तरों की कतार । मॉक सर्वर प्रतिक्रियाओं को फीफो कतार में जोड़ा जाता है। इससे कोई फर्क नहीं पड़ता कि मैं किस API और किस पथ पर पहुंचूंगा, नकली सर्वर इस कतार में संदेश फेंक रहा होगा।
• प्रेषणकर्ता आपको ऐसे नियम बनाने की अनुमति देता है जो यह निर्धारित करते हैं कि कौन सा उत्तर देना है। मान लीजिए कि एक URL एक पथ से आया है, उदाहरण के लिए / get-login /। इस / गेट-लॉगिन / मॉक सर्वर पर और एक एकल, पूर्वनिर्धारित प्रतिक्रिया देता है।
• सत्यापनकर्ता से अनुरोध करें । पिछले परिदृश्य के आधार पर, मैं उन अनुरोधों की जांच कर सकता हूं जो एप्लिकेशन भेजता है (जो दी गई शर्तों में, कुछ मापदंडों के साथ एक अनुरोध वास्तव में छोड़ देता है)। हालाँकि, उत्तर महत्वहीन है, क्योंकि यह निर्धारित करता है कि एपीआई कैसे काम करता है। यह स्क्रिप्ट अनुरोध सत्यापनकर्ता को लागू करती है।

प्रत्येक परिदृश्य पर अधिक विस्तार से विचार करें।

प्रतिक्रिया कतार

मॉक सर्वर का सबसे सरल कार्यान्वयन प्रतिक्रिया कतार है। परीक्षण से पहले, मैं पता और पोर्ट निर्धारित करता हूं जहां मॉक सर्वर को तैनात किया जाएगा, साथ ही इस तथ्य पर भी कि यह एक संदेश कतार के सिद्धांत पर काम करेगा - FIFO (पहली बार पहले बाहर)।

इसके बाद, मॉक सर्वर चलाएं।

class QueueTest: BaseTest() { @Rule @JvmField var mActivityRule: ActivityTestRule<MainActivity> = ActivityTestRule(MainActivity::class.java) @Before fun initMockServer() { val mockServer = MockWebServer() val ip = InetAddress.getByName("127.0.0.1") val port = 8080 mockServer.enqueue(MockResponse().setBody("1st message")) mockServer.enqueue(MockResponse().setBody("2nd message")) mockServer.enqueue(MockResponse().setBody("3rd message")) mockServer.start(ip, port) } @Test fun queueTest() { sendGetRequest("http://localhost:8080/getMessage") assertResponseMessage("1st message") returnFromResponseActivity() sendPostRequest("http://localhost:8080/getMessage") assertResponseMessage("2nd message") returnFromResponseActivity() sendGetRequest("http://localhost:8080/getMessage") assertResponseMessage("3rd message") returnFromResponseActivity() } } 

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

डिस्पैचर कार्यान्वयन

एक डिस्पैचर नियमों का एक समूह है जिसके द्वारा एक मॉक सर्वर संचालित होता है। सुविधा के लिए, मैंने तीन अलग-अलग डिस्पैचर बनाए: SimpleDispatcher, OtherParamsDispatcher और ListingDispatcher।

SimpleDispatcher

Okhttpmockwebserver Dispatcher() को लागू करने के लिए Dispatcher() वर्ग प्रदान करता है। आप इसे अपने तरीके से dispatch समारोह को ओवरराइड करके विरासत में प्राप्त कर सकते हैं।

 class SimpleDispatcher: Dispatcher() { @Override override fun dispatch(request: RecordedRequest): MockResponse { if (request.method == "GET"){ return MockResponse().setResponseCode(200).setBody("""{ "message": "It was a GET request" }""") } else if (request.method == "POST") { return MockResponse().setResponseCode(200).setBody("""{ "message": "It was a POST request" }""") } return MockResponse().setResponseCode(200) } } 

इस उदाहरण में तर्क सरल है: यदि कोई GET आता है, तो मैं एक संदेश देता हूं कि यह एक GET अनुरोध है। यदि POST, मैं POST अनुरोध के बारे में एक संदेश देता हूं। अन्य स्थितियों में, मैं एक खाली अनुरोध लौटाता हूं।

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

SimpleDispatcher साथ परीक्षण स्रोत भंडार में पाए जा सकते हैं।

OtherParamsDispatcher

dispatch समारोह को ओवरराइड करते हुए, मैं प्रतिक्रियाएं भेजने के लिए अन्य अनुरोध मापदंडों से हट सकता हूं:

 class OtherParamsDispatcher: Dispatcher() { @Override override fun dispatch(request: RecordedRequest): MockResponse { return when { request.path.contains("?queryKey=value") -> MockResponse().setResponseCode(200).setBody("""{ "message": "It was a GET request with query parameter queryKey equals value" }""") request.body.toString().contains("\"bodyKey\":\"value\"") -> MockResponse().setResponseCode(200).setBody("""{ "message": "It was a POST request with body parameter bodyKey equals value" }""") request.headers.toString().contains("header: value") -> MockResponse().setResponseCode(200).setBody("""{ "message": "It was some request with header equals value" }""") else -> MockResponse().setResponseCode(200).setBody("""{ Wrong response }""") } } } 

इस मामले में, मैं शर्तों के लिए कई विकल्पों का प्रदर्शन करता हूं।

सबसे पहले, आप एड्रेस बार में एपीआई को पैरामीटर पास कर सकते हैं। इसलिए, मैं पथ में किसी भी बंडल के प्रवेश पर एक शर्त रख सकता हूं, उदाहरण के लिए, “?queryKey=value” ।
दूसरे, यह वर्ग आपको POST या PUT अनुरोधों के मुख्य भाग के अंदर लाने की अनुमति देता है। उदाहरण के लिए, आप उपयोग कर सकते हैं पहले निष्पादित करके toString() । मेरे उदाहरण में, स्थिति तब उत्पन्न होती है जब “bodyKey”:”value” सहित एक POST अनुरोध “bodyKey”:”value” । इसी तरह, मैं अनुरोध header : value ( header : value ) को मान्य कर सकता हूं।

परीक्षणों के उदाहरणों के लिए, मैं रिपॉजिटरी को संदर्भित करने की सलाह देता हूं।

ListingDispatcher

यदि आवश्यक हो, तो आप एक अधिक जटिल तर्क को लागू कर सकते हैं - ListingDispatcher। उसी तरह, मैं dispatch समारोह को ओवरराइड करता हूं। हालाँकि, अब मैं कक्षा में ही सही अलग-अलग मौकों के लिए stubsList ( stubsList ) - mok का डिफ़ॉल्ट सेट stubsList ।

 class ListingDispatcher: Dispatcher() { private var stubsList: ArrayList<RequestClass> = defaultRequests() @Override override fun dispatch(request: RecordedRequest): MockResponse = try { stubsList.first { it.matcher(request.path, request.body.toString()) }.response() } catch (e: NoSuchElementException) { Log.e("Unexisting request path =", request.path) MockResponse().setResponseCode(404) } private fun defaultRequests(): ArrayList<RequestClass> { val allStubs = ArrayList<RequestClass>() allStubs.add(RequestClass("/get", "queryParam=value", "", """{ "message" : "Request url starts with /get url and contains queryParam=value" }""")) allStubs.add(RequestClass("/post", "queryParam=value", "", """{ "message" : "Request url starts with /post url and contains queryParam=value" }""")) allStubs.add(RequestClass("/post", "", "\"bodyParam\":\"value\"", """{ "message" : "Request url starts with /post url and body contains bodyParam:value" }""")) return allStubs } fun replaceMockStub(stub: RequestClass) { val valuesToRemove = ArrayList<RequestClass>() stubsList.forEach { if (it.path.contains(stub.path)&&it.query.contains(stub.query)&&it.body.contains(stub.body)) valuesToRemove.add(it) } stubsList.removeAll(valuesToRemove) stubsList.add(stub) } fun addMockStub(stub: RequestClass) { stubsList.add(stub) } } 

ऐसा करने के लिए, मैंने एक खुला वर्ग RequestClass बनाया, जिसके सभी फ़ील्ड डिफ़ॉल्ट रूप से खाली हैं। इस वर्ग के लिए, मैं एक response फ़ंक्शन को परिभाषित करता हूं जो MockResponse ऑब्जेक्ट (200 प्रतिसाद या कुछ अन्य responseText ), और एक matcher फ़ंक्शन बनाता है जो true या false देता true ।

 open class RequestClass(val path:String = "", val query: String = "", val body:String = "", val responseText: String = "") { open fun response(code: Int = 200): MockResponse = MockResponse() .setResponseCode(code) .setBody(responseText) open fun matcher(apiCall: String, apiBody: String): Boolean = apiCall.startsWith(path)&&apiCall.contains(query)&&apiBody.contains(body) } 

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

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

 fun replaceMockStub(stub: RequestClass) { val valuesToRemove = ArrayList<RequestClass>() stubsList.forEach { if (it.path.contains(stub.path)&&it.query.contains(stub.query)&&it.body.contains(stub.body)) valuesToRemove.add(it) } stubsList.removeAll(valuesToRemove) stubsList.add(stub) } 

डिस्पैचर के इस कार्यान्वयन के साथ, परीक्षण सरल रहते हैं। मैं भी मॉक सर्वर शुरू करता हूं, केवल ListingDispatcher चयन करें।

 class ListingDispatcherTest: BaseTest() { @Rule @JvmField var mActivityRule: ActivityTestRule<MainActivity> = ActivityTestRule(MainActivity::class.java) private val dispatcher = ListingDispatcher() @Before fun initMockServer() { val mockServer = MockWebServer() val ip = InetAddress.getByName("127.0.0.1") val port = 8080 mockServer.setDispatcher(dispatcher) mockServer.start(ip, port) } . . . } 

प्रयोग के लिए, मैंने स्टब को POST से बदल दिया:

 @Test fun postReplacedStubTest() { val params: HashMap<String, String> = hashMapOf("bodyParam" to "value") replacePostStub() sendPostRequest("http://localhost:8080/post", params = params) assertResponseMessage("""{ "message" : "Post request stub has been replaced" }""") } 

ऐसा करने के लिए, एक नियमित dispatcher से replacePostStub फ़ंक्शन को कॉल किया और एक नई response जोड़ी।

 private fun replacePostStub() { dispatcher.replaceMockStub(RequestClass("/post", "", "\"bodyParam\":\"value\"", """{ "message" : "Post request stub has been replaced" }""")) } 

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

 @Test fun getNewStubTest() { addSomeStub() sendGetRequest("http://localhost:8080/some_specific_url") assertResponseMessage("""{ "message" : "U have got specific message" }""") } 

 private fun addSomeStub() { dispatcher.addMockStub(RequestClass("/some_specific_url", "", "", """{ "message" : "U have got specific message" }""")) } 

सत्यापनकर्ता से अनुरोध करें

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

 @Test fun requestVerifierTest() { val params: HashMap<String, String> = hashMapOf("bodyKey" to "value") val headers: HashMap<String, String> = hashMapOf("header" to "value") sendPostRequest("http://localhost:8080/post", headers = headers, params = params) val request = mockServer.takeRequest() assertEquals("POST", request.method) assertEquals("value", request.getHeader("header")) assertTrue(request.body.toString().contains("\"bodyKey\":\"value\"")) assertTrue(request.path.startsWith("/post")) } 

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

परिणाम

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

लेख लेखक: रुस्लान अब्दुलिन

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