5 उन्नत गो परीक्षण तकनीकें

सभी को सलाम! "गोलंग डेवलपर" पाठ्यक्रम की शुरुआत से पहले एक सप्ताह से भी कम समय बचा है और हम विषय पर उपयोगी सामग्री साझा करना जारी रखते हैं। चलो चलते हैं!



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

परीक्षण सूट का उपयोग करें

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

 type Thinger interface { DoThing(input string) (Result, error) } // Suite tests all the functionality that Thingers should implement func Suite(t *testing.T, impl Thinger) { res, _ := impl.DoThing("thing") if res != expected { t.Fail("unexpected result") } } // TestOne tests the first implementation of Thinger func TestOne(t *testing.T) { one := one.NewOne() Suite(t, one) } // TestOne tests another implementation of Thinger func TestTwo(t *testing.T) { two := two.NewTwo() Suite(t, two) } 

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

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

आप यहां एक संपूर्ण उदाहरण पा सकते हैं। इस तथ्य के बावजूद कि यह उदाहरण दूर की कौड़ी है, कोई कल्पना कर सकता है कि एक डेटाबेस रिमोट है और दूसरा मेमोरी में है।

इस तकनीक का एक और अच्छा उदाहरण मानक पुस्तकालय में golang.org/x/net/nettest पैकेज में स्थित है। यह सत्यापित करने का साधन प्रदान करता है कि net.Conn इंटरफ़ेस को संतुष्ट कर रहा है।

इंटरफ़ेस संदूषण से बचें

आप गो में परीक्षण के बारे में बात नहीं कर सकते, लेकिन इंटरफेस के बारे में बात नहीं करते हैं।

परीक्षण के संदर्भ में इंटरफेस महत्वपूर्ण हैं, क्योंकि वे हमारे परीक्षण शस्त्रागार में सबसे शक्तिशाली उपकरण हैं, इसलिए आपको उन्हें सही तरीके से उपयोग करने की आवश्यकता है।

पैकेज अक्सर डेवलपर्स को इंटरफेस निर्यात करते हैं, और यह इस तथ्य की ओर जाता है कि:

ए) डेवलपर्स पैकेज को लागू करने के लिए अपना स्वयं का नकली बनाते हैं;
बी) पैकेज अपने स्वयं के नकली निर्यात करता है।

"बड़ा इंटरफ़ेस, कमजोर अमूर्तता"
- रोब पाइक, गोइंग का कहना है

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

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

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

संगामिति आदिम निर्यात न करें

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

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

• जब डेटा समाप्त हो जाता है तो चैनल पर भेजा जाता है।
• डेटा प्राप्त करते समय कोई त्रुटि थी।
• एक पैकेट पूरा होने के बाद चैनल को कैसे फ्लश करता है, अगर सब पर फ्लश हो?
• पैकेज API को कैसे लपेटें ताकि आप इसे सीधे कॉल न करें?

कतार पढ़ने के उदाहरण पर एक नज़र डालें। यहां एक उदाहरण पुस्तकालय है जो कतार से पढ़ता है और उपयोगकर्ता को पढ़ने के लिए फ़ीड प्रदान करता है।

 type Reader struct {...} func (r *Reader) ReadChan() <-chan Msg {...} 

अब आपका पुस्तकालय उपयोगकर्ता अपने उपभोक्ता के लिए एक परीक्षण लागू करना चाहता है:

 func TestConsumer(t testing.T) { cons := &Consumer{ r: libqueue.NewReader(), } for msg := range cons.r.ReadChan() { // Test thing. } } 

उपयोगकर्ता तब यह तय कर सकता है कि निर्भरता इंजेक्शन एक अच्छा विचार है और चैनल में अपने स्वयं के संदेश लिखें:

 func TestConsumer(t testing.T, q queueIface) { cons := &Consumer{ r: q, } for msg := range cons.r.ReadChan() { // Test thing. } } 

रुको, त्रुटियों के बारे में क्या?

 func TestConsumer(t testing.T, q queueIface) { cons := &Consumer{ r: q, } for { select { case msg := <-cons.r.ReadChan(): // Test thing. case err := <-cons.r.ErrChan(): // What caused this again? } } } 

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

 func TestConsumer(t testing.T, q queueIface) { cons := &Consumer{ r: q, } msg, err := cons.r.ReadMsg() // handle err, test thing } 

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

net/http/httptest उपयोग करें

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

यहाँ एक ही परीक्षण को दो तरीकों से लागू किया गया है। यहां कुछ भी भव्य नहीं है, लेकिन यह दृष्टिकोण कोड की मात्रा को कम करता है और संसाधनों को बचाता है।

 func TestServe(t *testing.T) { // The method to use if you want to practice typing s := &http.Server{ Handler: http.HandlerFunc(ServeHTTP), } // Pick port automatically for parallel tests and to avoid conflicts l, err := net.Listen("tcp", ":0") if err != nil { t.Fatal(err) } defer l.Close() go s.Serve(l) res, err := http.Get("http://" + l.Addr().String() + "/?sloths=arecool") if err != nil { log.Fatal(err) } greeting, err := ioutil.ReadAll(res.Body) res.Body.Close() if err != nil { log.Fatal(err) } fmt.Println(string(greeting)) } func TestServeMemory(t *testing.T) { // Less verbose and more flexible way req := httptest.NewRequest("GET", "http://example.com/?sloths=arecool", nil) w := httptest.NewRecorder() ServeHTTP(w, req) greeting, err := ioutil.ReadAll(w.Body) if err != nil { log.Fatal(err) } fmt.Println(string(greeting)) } 

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

इस सिद्धांत को कार्रवाई में देखने के लिए, मार्क बर्जर के लेख को देखें ।

अलग पैकेज _test उपयोग करें

पारिस्थितिकी तंत्र में अधिकांश परीक्षण pkg_test.go फ़ाइलों में बनाए जाते हैं, लेकिन फिर भी एक ही पैकेज में रहते हैं: package pkg । एक अलग परीक्षण पैकेज वह पैकेज है जिसे आप नई फ़ाइल में बनाते हैं, foo_test.go , उस मॉड्यूल की निर्देशिका में जिसे आप परीक्षण करना चाहते हैं, foo/ , घोषणा package foo_test । यहाँ से आप github.com/example/foo और अन्य निर्भरताएँ आयात कर सकते हैं। यह सुविधा आपको कई काम करने की अनुमति देती है। यह परीक्षणों में चक्रीय निर्भरता के लिए अनुशंसित समाधान है, यह "भंगुर परीक्षणों" की उपस्थिति को रोकता है और डेवलपर को यह महसूस करने की अनुमति देता है कि वह अपने पैकेज का उपयोग करने के लिए कैसा है। यदि आपके पैकेज का उपयोग करना मुश्किल है, तो इस पद्धति के साथ परीक्षण करना भी मुश्किल होगा।

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

अंत में, यह परीक्षणों में आयात चक्र से बचने में मदद करता है। अधिकांश पैकेजों के परीक्षण पैकेजों के अलावा आपके द्वारा लिखे गए अन्य पैकेजों पर निर्भर होने की अधिक संभावना है, इसलिए आप एक ऐसी स्थिति के साथ समाप्त हो जाएंगे जहां आयात चक्र स्वाभाविक रूप से होता है। पैकेज पदानुक्रम में दोनों पैकेज के ऊपर एक बाहरी पैकेज स्थित है। द गो प्रोग्रामिंग लैंग्वेज (चैप्टर 11 सेक्शन 2.4) से एक उदाहरण लें, जहां net/url एक URL पार्सर को लागू करता है जो net/http उपयोग करने के लिए आयात करता है। हालांकि, net / url को net / http आयात करके वास्तविक उपयोग के मामले के साथ परीक्षण करने की आवश्यकता है। इस प्रकार net/url_test ।

अब, जब आप एक अलग परीक्षण पैकेज का उपयोग करते हैं, तो आपको उस पैकेज में अप्रमाणित संस्थाओं तक पहुँच की आवश्यकता हो सकती है जहाँ वे पहले उपलब्ध थे। कुछ डेवलपर्स का सामना पहली बार तब किया जाता है जब समय के आधार पर किसी चीज़ का परीक्षण किया जाता है (उदाहरण के लिए, time.Now एक फ़ंक्शन का उपयोग करके स्टब बन जाता है)। इस मामले में, हम विशेष रूप से परीक्षण के दौरान संस्थाओं को प्रदान करने के लिए एक अतिरिक्त फ़ाइल का उपयोग कर सकते हैं, क्योंकि _test.go फाइलें नियमित बिल्ड से बाहर रखी _test.go ।

आपको याद रखने की आवश्यकता क्या है?

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

गो के साथ परीक्षण के बारे में अधिक जानना चाहते हैं?
ये लेख पढ़ें:

डेव चेनी की राइटिंग टेबल ड्रिवेन टेस्ट इन गो
परीक्षण पर जाओ प्रोग्रामिंग भाषा अध्याय।
या ये वीडियो देखें:
गोशिकोन 2017 से हाशिमोतो की एडवांस्ड टेस्टिंग विथ गो टॉक
एंड्रयू जेरैंड की टेस्टिंग तकनीक 2014 से बात करती है

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