हम वास्तविक स्टॉक रिटर्न का मूल्यांकन करने के लिए गो और जावास्क्रिप्ट में एक लर्निंग एप्लीकेशन लिख रहे हैं। भाग 2 - बैकेंड का परीक्षण

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

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


चित्र यहाँ से

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

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

सबसे पहले, परीक्षण पद्धति के बारे में कुछ शब्द जो मैं गो कार्यक्रमों के लिए उपयोग करता हूं।

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

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

दूसरे , परीक्षण लिखने के समय के बारे में कुछ शब्द। जैसा कि सभी जानते हैं, यूनिट टेस्ट कब लिखना है, इसके बारे में अलग-अलग राय है। मुख्य विचार इस प्रकार हैं:

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

मुझे नहीं लगता कि इस विषय पर एकमात्र सही राय है। मैं अपना साझा करूंगा और पाठकों से टिप्पणियों में टिप्पणी करने के लिए कहूंगा। मेरी राय यह है:

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

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

चलो रिपॉजिटरी को लागू करने के लिए परीक्षणों से शुरू करते हैं।

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

कंस्ट्रक्टर का परीक्षण करना (ओओपी शर्तों का उपयोग, अनौपचारिक रूप से किया जाता है। गो में ओओपी की स्थिति के अनुसार पूर्ण रूप से)।

//    func TestNew(t *testing.T) { //   - memoryStorage := New() //     var s *Storage //         .   if reflect.TypeOf(memoryStorage) != reflect.TypeOf(s) { t.Errorf(" :  %v,   %v", reflect.TypeOf(memoryStorage), reflect.TypeOf(s)) } //     t.Logf("\n%+v\n\n", memoryStorage) } 

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

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

उद्धरण परीक्षण।

 //    func TestSecurities(t *testing.T) { //     var s *Storage //    ss, err := s.Securities() if err != nil { t.Error(err) } //     t.Logf("\n%+v\n\n", ss) } } 

यहाँ सब कुछ बहुत स्पष्ट है।

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

 //    func TestAdd(t *testing.T) { //     var s *Storage var security = storage.Security{ ID: "MSFT", } //   var tt = []struct { s storage.Security //   length int //   () }{ { s: security, length: 1, }, { s: security, length: 2, }, } var ss []storage.Security // tc - test case, tt - table tests for _, tc := range tt { //    err := s.Add(security) if err != nil { t.Error(err) } ss, err = s.Securities() if err != nil { t.Error(err) } if len(ss) != tc.length { t.Errorf("  :  %d,   %d", len(ss), tc.length) } } //     t.Logf("\n%+v\n\n", ss) } 

खैर, डेटा आरंभीकरण समारोह के लिए एक परीक्षण।

 //    func TestInitData(t *testing.T) { //     var s *Storage //    err := s.InitData() if err != nil { t.Error(err) } ss, err := s.Securities() if err != nil { t.Error(err) } if len(ss) < 1 { t.Errorf(" :  %d,   '> 1'", len(ss)) } //     t.Logf("\n%+v\n\n", ss[0]) } 

सफल परीक्षण निष्पादन के परिणामस्वरूप, हम प्राप्त करते हैं: 17.595s कवरेज: 86.0% कथन।

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

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

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

सच है, एक और राय है (और न केवल मेरी) कि वास्तविक डेटा में हेरफेर के लिए सिस्टम लॉजिक को अलग करना अच्छा है।

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

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

 //    -    type stub int //      var securities []storage.Security //    // ******************************* //     // InitData      func (s *stub) InitData() (err error) { //   -   var security = storage.Security{ ID: "MSFT", Name: "Microsoft", IssueDate: 1514764800, // 01/01/2018 } var quote = storage.Quote{ SecurityID: "MSFT", Num: 0, TimeStamp: 1514764800, Price: 100, } security.Quotes = append(security.Quotes, quote) securities = append(securities, security) return err } // Securities      func (s *stub) Securities() (data []storage.Security, err error) { return securities, err } //   // ***************** 

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

 func TestMain(m *testing.M) 

यह फ़ंक्शन आपको सभी परीक्षणों को शुरू करने और चलाने की अनुमति देता है। यह कुछ इस तरह दिखता है:

 //    -   func TestMain(m *testing.M) { //     -    db = new(stub) //   () db.InitData() //     os.Exit(m.Run()) } 

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

 //    func TestSecuritiesHandler(t *testing.T) { //     req, err := http.NewRequest(http.MethodGet, "/api/v1/securities", nil) if err != nil { t.Fatal(err) } // ResponseRecorder    rr := httptest.NewRecorder() handler := http.HandlerFunc(securitiesHandler) //       handler.ServeHTTP(rr, req) //  HTTP-  if rr.Code != http.StatusOK { t.Errorf(" :  %v,   %v", rr.Code, http.StatusOK) } //  ()     json    var ss []storage.Security err = json.NewDecoder(rr.Body).Decode(&ss) if err != nil { t.Fatal(err) } //       t.Logf("\n%+v\n\n", ss) } 

परीक्षण का सार यह है: एक HTTP अनुरोध बनाएं, सर्वर प्रतिक्रिया की रिकॉर्डिंग के लिए एक संरचना को परिभाषित करें, अनुरोध हैंडलर शुरू करें, प्रतिक्रिया निकाय को डीकोड करें (संरचना में json)। खैर, स्पष्टता के लिए, हम उत्तर को प्रिंट करते हैं।

यह कुछ इस प्रकार है:

=== रन टेस्ट सिक्योरिटी हैन्डलर
0xc00005e3e0
- पास: TestSecuritiesHandler (0.00s)
c: \ Users \ dtsp \ YandexDisk \ go \ src \ moex_etf \ server \ server_test.go: 96:
[{आईडी: MSFT नाम: Microsoft जारी: १५१४800६४otes०० उद्धरण: [{सुरक्षा: एमएसएफटी अंक: ० टाइमस्टैम्प: १५१४64६४ Price०० मूल्य: १००}]]]

पास
ठीक moex_etf / सर्वर 0.307 s
सफलता: टेस्ट पास हुए।

गिथब कोड।

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