📶 👨🏾‍🎓 😰 गोनकी - माइक्रोसर्विस टेस्टिंग टूल 🙏🏾 🤶 💇🏼

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

नीचे मैं इसके बारे में अधिक विस्तार से बात करूंगा और विशिष्ट उदाहरणों के साथ दिखाऊंगा कि इसका उपयोग कैसे करना है।

गोनकी का जन्म कैसे हुआ था

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

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

एपीआई डिजाइन के लिए मानक दृष्टिकोण स्वाभाविक रूप से परीक्षण के लिए एक मानक दृष्टिकोण के विचार का कारण बना। यहाँ मैं क्या हासिल करना चाहता था:

एपीआई के माध्यम से सेवाओं का परीक्षण करें , क्योंकि सेवा की लगभग सभी कार्यक्षमता इसके माध्यम से कार्यान्वित की जाती है
जैसा कि वे कहते हैं, "हमारे CI / CD प्रक्रिया में एकीकृत करने के लिए परीक्षणों के प्रक्षेपण को स्वचालित करने की क्षमता ," बटन द्वारा संचालित "
लेखन परीक्षण अलग-थलग होना चाहिए , अर्थात् , न केवल एक प्रोग्रामर परीक्षण लिख सकता है, आदर्श रूप से एक व्यक्ति जो प्रोग्रामिंग से परिचित नहीं है।

तो गोनकी का जन्म हुआ।

तो यह क्या है?

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

सीधे शब्दों में कहें, गोनकी कर सकते हैं:

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

प्रोजेक्ट रिपॉजिटरी
डॉकटर छवि

गोनकी के साथ सेवा परीक्षण उदाहरण

आपको पाठ के साथ बोझ न करने के लिए, मैं शब्दों से कर्मों की ओर जाना चाहता हूं और यहीं कुछ एपीआई का परीक्षण करता हूं और बताता हूं कि कैसे रास्ते में परीक्षण स्क्रिप्ट लिखी जाती हैं।

चलो गो पर एक छोटी सी सेवा को स्केच करें जो ट्रैफिक लाइट के काम का अनुकरण करेगी। यह वर्तमान संकेत के रंग को संग्रहीत करता है: लाल, पीला या हरा। आप वर्तमान सिग्नल का रंग प्राप्त कर सकते हैं या एपीआई के माध्यम से एक नया सेट कर सकते हैं।

//    const ( lightRed = "red" lightYellow = "yellow" lightGreen = "green" ) //      type trafficLights struct { currentLight string `json:"currentLight"` mutex sync.RWMutex `json:"-"` } //   var lights = trafficLights{ currentLight: lightRed, } func main() { //       http.HandleFunc("/light/get", func(w http.ResponseWriter, r *http.Request) { lights.mutex.RLock() defer lights.mutex.RUnlock() resp, err := json.Marshal(lights) if err != nil { log.Fatal(err) } w.Write(resp) }) //       http.HandleFunc("/light/set", func(w http.ResponseWriter, r *http.Request) { lights.mutex.Lock() defer lights.mutex.Unlock() request, err := ioutil.ReadAll(r.Body) if err != nil { log.Fatal(err) } var newTrafficLights trafficLights if err := json.Unmarshal(request, &newTrafficLights); err != nil { http.Error(w, err.Error(), http.StatusBadRequest) return } if err := validateRequest(&newTrafficLights); err != nil { http.Error(w, err.Error(), http.StatusBadRequest) return } lights = newTrafficLights }) //   () log.Fatal(http.ListenAndServe(":8080", nil)) } func validateRequest(lights *trafficLights) error { if lights.currentLight != lightRed && lights.currentLight != lightYellow && lights.currentLight != lightGreen { return fmt.Errorf("incorrect current light: %s", lights.currentLight) } return nil }

Main.go के लिए पूर्ण स्रोत कोड यहाँ है ।

प्रोग्राम चलाएँ:

 go run .

15 मिनट में बहुत तेजी से स्केच किया! निश्चित रूप से वह कहीं गलत था, इसलिए हम परीक्षण और जांच लिखेंगे।

गोनकी डाउनलोड और चलाएं:

 mkdir -p tests/cases docker run -it -v $(pwd)/tests:/tests lamoda/gonkey -tests tests/cases -host host.docker.internal:8080

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

यदि आपको डॉकटर दृष्टिकोण पसंद नहीं है, तो इस तरह के कमांड का एक विकल्प लिखना होगा:

 go get github.com/lamoda/gonkey go run github.com/lamoda/gonkey -tests tests/cases -host localhost:8080

लॉन्च किया गया और परिणाम मिला:

 Failed tests: 0/0

कोई परीक्षण नहीं - जाँच करने के लिए कुछ भी नहीं। पहला टेस्ट लिखते हैं। न्यूनतम सामग्री के साथ एक फ़ाइल परीक्षण / मामलों / light_get.yaml बनाएँ:

 - name: WHEN currentLight is requested MUST return red method: GET path: /light/get response: 200: > { "currentLight": "red" }

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

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

पूर्ण फ़ाइल प्रारूप README में वर्णित है ।

फिर से चलाएं:

 docker run -it -v $(pwd)/tests:/tests lamoda/gonkey -tests tests/cases -host host.docker.internal:8080

परिणाम:

  Name: WHEN currentlight is requested MUST return red Request: Method: GET Path: /light/get Query: Body: <no body> Response: Status: 200 OK Body: {} Result: ERRORS! Errors: 1) at path $ values do not match: expected: { "currentLight": "red" } actual: {} Failed tests: 1/1

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

  expected: { "currentLight": "red" }

कारण सरल है: मैं लिखना भूल गया ताकि प्रतिक्रिया में सेवा सामग्री प्रकार के आवेदन / json को इंगित करे। हम ठीक करते हैं:

 //       http.HandleFunc("/light/get", func(w http.ResponseWriter, r *http.Request) { lights.mutex.RLock() defer lights.mutex.RUnlock() resp, err := json.Marshal(lights) if err != nil { log.Fatal(err) } w.Header().Add("Content-Type", "application/json") // <--  w.Write(resp) })

हम सेवा को पुनः आरंभ करते हैं और फिर से परीक्षण चलाते हैं:

  Name: WHEN currentlight is requested MUST return red Request: Method: GET Path: /light/get Query: Body: <no body> Response: Status: 200 OK Body: {} Result: ERRORS! Errors: 1) at path $ key is missing: expected: currentLight actual: <missing>

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

 //      type trafficLights struct { currentLight string `json:"currentLight"` mutex sync.RWMutex `json:"-"` }

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

 //      type trafficLights struct { urrentLight string `json:"currentLight"` // <--   mutex sync.RWMutex `json:"-"` }

सेवा को पुनरारंभ करें। फिर से परीक्षण चलाएं।

 Failed tests: 0/1

इम्तिहान पास हो गए!

हम दूसरी स्क्रिप्ट लिखेंगे जो सेट विधि का परीक्षण करेगी। निम्नलिखित सामग्री के साथ फ़ाइल परीक्षण / मामले / light_set.yaml भरें:

 - name: WHEN set is requested MUST return no response method: POST path: /light/set request: > { "currentLight": "green" } response: 200: '' - name: WHEN get is requested MUST return green method: GET path: /light/get response: 200: > { "currentLight": "green" }

पहला परीक्षण ट्रैफ़िक सिग्नल के लिए एक नया मान निर्धारित करता है, और दूसरा यह सुनिश्चित करने के लिए स्थिति की जांच करता है कि यह बदल गया है।

एक ही आदेश के साथ परीक्षण चलाएं:

 docker run -it -v $(pwd)/tests:/tests lamoda/gonkey -tests tests/cases -host host.docker.internal:8080

परिणाम:

 Failed tests: 0/3

एक सफल परिणाम, लेकिन हम भाग्यशाली थे कि स्क्रिप्ट को उस क्रम में निष्पादित किया गया जिसकी हमें आवश्यकता थी: पहले light_get, और फिर light_set। अगर उन्होंने इसके विपरीत किया तो क्या होगा? चलो नाम बदलें:

 mv tests/cases/light_set.yaml tests/cases/_light_set.yaml

और फिर से दौड़ें:

 Errors: 1) at path $.currentLight values do not match: expected: red actual: green Failed tests: 1/3

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

इस तथ्य से छुटकारा पाने का एक तरीका है कि परीक्षण संदर्भ पर निर्भर करता है, स्क्रिप्ट की शुरुआत (यानी, फ़ाइल की शुरुआत में) सेवा शुरू करने के लिए है, जिसे हम आम तौर पर सेट परीक्षण में करते हैं - पहले हम ज्ञात मूल्य निर्धारित करते हैं, जो एक ज्ञात प्रभाव पैदा करता है, और फिर जांच लें कि प्रभाव का प्रभाव था।

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

इस बीच, मैं निम्नलिखित समाधान का प्रस्ताव करता हूं। चूंकि सेट स्क्रिप्ट में हम वास्तव में प्रकाश / सेट विधि और प्रकाश / प्राप्त विधि दोनों का परीक्षण कर रहे हैं, हमें बस light_get स्क्रिप्ट की आवश्यकता नहीं है, जो कि संदर्भ संवेदनशील है। मैं इसे हटा देता हूं, और शेष स्क्रिप्ट का नाम बदल देता हूं ताकि नाम सार को दर्शाता है।

 rm tests/cases/light_get.yaml mv tests/cases/_light_set.yaml tests/cases/light_set_get.yaml

अगले चरण के रूप में, मैं हमारी सेवा के साथ काम करने के कुछ नकारात्मक परिदृश्यों की जांच करना चाहता हूं, उदाहरण के लिए, क्या यह सही ढंग से काम करेगा अगर मैं गलत तरीके से रंग भेजूं? या रंग बिल्कुल नहीं भेजते?

एक नया परीक्षण / मामले बनाएँ / light_set_get_negative.yaml स्क्रिप्ट:

 - name: WHEN set is requested MUST return no response method: POST path: /light/set request: > { "currentLight": "green" } response: 200: '' - name: WHEN incorrect color is passed MUST return error method: POST path: /light/set request: > { "currentLight": "blue" } response: 400: > incorrect current light: blue - name: WHEN color is missing MUST return error method: POST path: /light/set request: > {} response: 400: > incorrect current light: - name: WHEN get is requested MUST have color untouched method: GET path: /light/get response: 200: > { "currentLight": "green" }

वह जाँचता है कि:

जब गलत रंग प्रसारित होता है, तो एक त्रुटि होती है;
जब रंग प्रसारित नहीं होता है, तो एक त्रुटि होती है;
गलत रंग संचरण यातायात प्रकाश की आंतरिक स्थिति को नहीं बदलता है।

चलाएँ:

 Failed tests: 0/6

सब कुछ ठीक है :)

गोनकी को एक पुस्तकालय के रूप में जोड़ना

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

लेकिन हमारे स्वयं के अनुप्रयोगों के लिए लिखित रूप में, गोनकी को चलाने के लिए एक और अधिक सुविधाजनक तरीका है - इसे एक पुस्तकालय के रूप में परियोजना से जोड़ने के लिए। यह अग्रिम में कुछ भी संकलित किए बिना - न तो गोनकी, और न ही परियोजना - केवल go test चलाकर चलाने की अनुमति देगा।

इस दृष्टिकोण के साथ, हम एक इकाई परीक्षण लिखना शुरू करते हैं, और परीक्षण के शरीर में हम निम्नलिखित करते हैं:

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

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

मैंने निम्नलिखित कोड को एक अलग फ़ंक्शन में रखा है:

 func initServer() { //       http.HandleFunc("/light/get", func(w http.ResponseWriter, r *http.Request) { //   }) //       http.HandleFunc("/light/set", func(w http.ResponseWriter, r *http.Request) { //   }) }

मुख्य कार्य इस प्रकार होगा:

 func main() { initServer() //   () log.Fatal(http.ListenAndServe(":8080", nil)) }

पूरी तरह से संशोधित मुख्य गो फ़ाइल ।

इसने हमारे हाथों को मुक्त कर दिया, तो चलिए एक परीक्षा लिखना शुरू करते हैं। मैं एक func_test.go फ़ाइल बनाता हूं:

 func Test_API(t *testing.T) { initServer() srv := httptest.NewServer(nil) runner.RunWithTesting(t, &runner.RunWithTestingParams{ Server: srv, TestsDir: "tests/cases", }) }

यहाँ पूर्ण func_test.go फ़ाइल है ।

वह सब है! हम जाँच करते हैं:

 go test ./...

परिणाम:

 ok github.com/lamoda/gonkey/examples/traffic-lights-demo 0.018s

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

एक एल्योर रिपोर्ट बनाएँ

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

 docker run -it -v $(pwd)/tests:/tests -w /tests lamoda/gonkey -tests cases/ -host host.docker.internal:8080 -allure

रिपोर्ट को वर्तमान कार्यशील निर्देशिका के एल्योर-रिजल्ट सबडायरेक्ट में रखा जाएगा (इसीलिए मैंने -w / परीक्षण निर्दिष्ट किया है)।

गोनकी को एक पुस्तकालय के रूप में जोड़ने पर, एक अतिरिक्त पर्यावरण चर GONKEY_ALLURE_DIR को सेट करके Allure रिपोर्ट सक्रिय हो जाती है:

 GONKEY_ALLURE_DIR="tests/allure-results" go test ./…

फाइलों में दर्ज किए गए परीक्षा परिणाम कमांड द्वारा एक इंटरैक्टिव रिपोर्ट में बदल दिए जाते हैं:

 allure generate allure serve

रिपोर्ट कैसी दिखती है:

निष्कर्ष

निम्नलिखित लेखों में, मैं गोनकी में जुड़नार के उपयोग पर और मोज़ेक का उपयोग करके अन्य सेवाओं की प्रतिक्रियाओं की नकल करने पर ध्यान दूंगा।

मैं आपको अपनी परियोजनाओं में गोनकी की कोशिश करने के लिए आमंत्रित करता हूं, इसके विकास में भाग लेता हूं (पूल अनुरोधों का स्वागत है!) या इसे गितुब पर एक तारांकन चिह्न के साथ चिह्नित करें यदि यह परियोजना भविष्य में आपके लिए उपयोगी हो सकती है।

गोनकी - माइक्रोसर्विस टेस्टिंग टूल

गोनकी का जन्म कैसे हुआ था

तो यह क्या है?

गोनकी के साथ सेवा परीक्षण उदाहरण

गोनकी को एक पुस्तकालय के रूप में जोड़ना

एक एल्योर रिपोर्ट बनाएँ

निष्कर्ष

More articles: