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

कार्यक्रम का उद्देश्य

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

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

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

समाधान अधूरा है, इसकी कई सीमाएं हैं, जो आरईएडीएमई में वर्णित हैं। किसी भी मामले में, यह एक मुकाबला परियोजना नहीं है।

उदाहरण और स्रोत कोड का उपयोग करें ।

पहली मुश्किलें

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

इसका समाधान github.com/jmoiron/sqlx से MapScan विधि का उपयोग करना था, जिसने नमूना कॉलम की संख्या के बराबर आकार में एक इंटरफ़ेस टुकड़ा बनाया। अगला सवाल था कि इन इंटरफेस से वास्तविक डेटा प्रकार कैसे प्राप्त किया जाए। समाधान प्रकार द्वारा एक स्विच-केस है । ऐसा समाधान बहुत सुंदर नहीं दिखता है, क्योंकि सभी प्रकारों को स्ट्रिंग में डालने की आवश्यकता होगी: पूर्णांक के रूप में वे हैं, तार के निशान से बचने और संलग्न होने के लिए तार, लेकिन एक ही समय में डेटाबेस से आने वाले सभी प्रकारों का वर्णन करने के लिए। मुझे इस मुद्दे को हल करने के लिए अधिक सुरुचिपूर्ण तरीका नहीं मिला।

प्रकारों के साथ, एक गो भाषा सुविधा भी प्रकट हुई थी - प्रकार स्ट्रिंग का एक चर मान nil नहीं ले सकता है, लेकिन रिक्त स्ट्रिंग और NULL दोनों डेटाबेस से आ सकते हैं। इस समस्या को हल करने के लिए, database/sql पैकेज में एक समाधान है - विशेष strut उपयोग करें, जो मूल्य और हस्ताक्षर को संग्रहीत करते हैं, चाहे वह NULL या नहीं।

विधानसभा और परीक्षणों द्वारा कोड कवरेज के प्रतिशत की गणना

असेंबली के लिए मैं ट्रैविस सीआई का उपयोग करता हूं, परीक्षणों के साथ कोड कवरेज का प्रतिशत प्राप्त करने के लिए - कवरॉल। विधानसभा के लिए .travis.yml फ़ाइल काफी सरल है:

 language: go go: - 1.9 script: - go get -t -v ./... - go get golang.org/x/tools/cmd/cover - go get github.com/mattn/goveralls - go test -v -covermode=count -coverprofile=coverage.out ./... - $HOME/gopath/bin/goveralls -coverprofile=coverage.out -service=travis-ci -repotoken $COVERALLS_TOKEN

ट्रैविस सीआई सेटिंग्स में, आपको केवल पर्यावरण चर COVERALLS_TOKEN को निर्दिष्ट करना होगा, जिसका मूल्य साइट पर लिया जाना चाहिए।

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

कोड के 100% कवरेज का मतलब है कि परीक्षण में लिखा गया है कि, अन्य बातों के अलावा, if में प्रत्येक शाखा के लिए कोड निष्पादित करें। परीक्षण लिखते समय, और सामान्य तौर पर, अनुप्रयोग विकसित करते समय यह सबसे अधिक काम आता है।

आप स्थानीय स्तर पर परीक्षणों के साथ कवरेज की गणना कर सकते हैं, उदाहरण के लिए, उसी go test -v -covermode=count -coverprofile=coverage.out ./... , लेकिन आप इसे CI में अधिक अच्छी तरह से कर सकते हैं, आप go test -v -covermode=count -coverprofile=coverage.out ./... पर एक प्लेट रख सकते हैं।

चूंकि हम पासा के बारे में बात कर रहे हैं, तो मुझे https://goreportcard.com से पासा उपयोगी लगता है, जो निम्नलिखित संकेतकों का विश्लेषण करता है:

gofmt - कोड स्वरूपण, जिसमें निर्माण का सरलीकरण शामिल है
go_vet - संदिग्ध निर्माणों की जाँच करता है
gocyclo - चक्रीय जटिलता में समस्याओं को दर्शाता है
golint - मेरे लिए यह सभी आवश्यक टिप्पणियों की उपलब्धता की जाँच कर रहा है
लाइसेंस - परियोजना के पास लाइसेंस होना चाहिए
अप्रभावी - अप्रभावी कार्य के लिए जाँच
misspell - टाइपोस के लिए जाँच

100% परीक्षणों के साथ कोड को कवर करने में कठिनाई

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

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

एक अन्य विकल्प मेमोरी में डेटाबेस का उपयोग करने के लिए हो सकता है, उदाहरण के लिए, sqlite ( sqlx.Open("sqlite3", ":memory:") ), लेकिन इसका मतलब है कि कोड जितना संभव हो सके डेटाबेस इंजन से बंधा होना चाहिए और यह प्रोजेक्ट को बहुत जटिल बनाता है लेकिन एकीकरण परीक्षण के लिए काफी अच्छा है।

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

लेखन परीक्षणों से पता चला है कि वास्तविक डेटाबेस से जुड़ने वाले फ़ंक्शन को main.go में स्थानांतरित करने की आवश्यकता है, इसलिए इसे मॉक उदाहरण को वापस करने वाले के लिए परीक्षणों में पुनः परिभाषित किया जा सकता है।

डेटाबेस के साथ काम करने के अलावा, फ़ाइल सिस्टम के साथ काम को एक अलग निर्भरता बनाना आवश्यक है। यह परीक्षण की आसानी के लिए मेमोरी के साथ वास्तविक फ़ाइलों की रिकॉर्डिंग को बदलने और युग्मन को कम करने की अनुमति देगा। यह है कि FileWriter इंटरफ़ेस कैसे दिखाई दिया, और इसके साथ फ़ाइल का इंटरफ़ेस जो इसे लौटाता है। त्रुटि परिदृश्यों का परीक्षण करने के लिए, इन इंटरफेसों के सहायक कार्यान्वयनों को बनाया और filewriter_test.go फ़ाइल में रखा गया था, इसलिए वे सामान्य बिल्ड में नहीं आते हैं, लेकिन परीक्षणों में उपयोग किया जा सकता है।

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

गो परीक्षण में " उदाहरण फ़ंक्शंस " जैसी कोई चीज़ है। ये परीक्षण फ़ंक्शन हैं जो इस तरह के फ़ंक्शन के अंदर टिप्पणी में वर्णित के साथ आउटपुट की तुलना करते हैं। ऐसे परीक्षणों के उदाहरणों को गो पैकेज के स्रोत कोड में पाया जा सकता है । यदि ऐसी फ़ाइलों में परीक्षण और बेंचमार्क नहीं होते हैं, तो उन्हें उपसर्ग example_ साथ नामित किया जाता है और _test.go साथ समाप्त _test.go । ऐसे प्रत्येक परीक्षण समारोह का नाम Example साथ शुरू होना चाहिए। इस पर, मैंने एक ऑब्जेक्ट के लिए एक परीक्षण लिखा, जो फ़ाइल में sql लिखता है, फ़ाइल में वास्तविक रिकॉर्ड को एक नकली के साथ बदल देता है, जिससे आप सामग्री प्राप्त कर सकते हैं और उन्हें प्रदर्शित कर सकते हैं। इस निष्कर्ष की तुलना मानक के साथ की जाती है। आसानी से, आपको अपने हाथों से तुलना लिखने की ज़रूरत नहीं है, और टिप्पणियों में कुछ पंक्तियाँ लिखना सुविधाजनक है। लेकिन जब यह एक ऐसे ऑब्जेक्ट के लिए परीक्षण के लिए आया, जो डेटा को csv फ़ाइल में लिखता है, तो कठिनाइयाँ उत्पन्न होती हैं। RFC4180 के अनुसार , CSV में लाइनों को CRLF द्वारा अलग किया जाना चाहिए, और go fmt जगह LF के साथ सभी लाइनों को बदल दिया जाता है, जो इस तथ्य की ओर जाता है कि टिप्पणी से मानक अलग-अलग लाइन के कारण वास्तविक आउटपुट के साथ मेल नहीं खाता है। मुझे इस ऑब्जेक्ट के लिए एक नियमित परीक्षण लिखना था, जबकि example_ से इसे हटाकर फ़ाइल का नाम बदलना भी था।

यह सवाल बना हुआ है, यदि फ़ाइल, उदाहरण के लिए, query.go उपयोग उदाहरण और साधारण परीक्षण दोनों का उपयोग करके किया query.go है, तो क्या दो फ़ाइल example_query_test.go और query_test.go होनी चाहिए? यहाँ, उदाहरण के लिए, केवल एक example_test.go । "गो परीक्षण उदाहरण" की खोज का उपयोग अभी भी मजेदार है।

मैंने Google को "गो राइटिंग टेस्ट" के लिए दिए जाने वाले गाइड के अनुसार परीक्षण लिखना सीखा। मैं ( 1 , 2 , 3 , 4 ) भर में आने वाले अधिकांश लोगों ने फॉर्म के अपेक्षित डिजाइन के साथ परिणाम की तुलना करने का सुझाव दिया

 if v != 1.5 { t.Error("Expected 1.5, got ", v) }

लेकिन जब यह प्रकारों की तुलना करने की बात आती है, तो एक परिचित निर्माण "प्रतिबिंबित" या प्रकार के जोर के उपयोग के विकास में विकसित होता है। या एक अन्य उदाहरण, जब आपको जांचने की आवश्यकता है कि टुकड़ा या मानचित्र का आवश्यक मूल्य है। कोड बोझिल हो जाता है। इसलिए मैं परीक्षण के लिए अपने सहायक कार्यों को लिखना चाहता हूं। यद्यपि यहां एक अच्छा समाधान परीक्षण के लिए पुस्तकालय का उपयोग करना है। मुझे https://github.com/stretchr/testify मिला। यह आपको एक ही पंक्ति में तुलना करने की अनुमति देता है। यह समाधान कोड की मात्रा को कम करता है और परीक्षणों के पढ़ने और समर्थन को सरल करता है।

कोड विखंडन और परीक्षण

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

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

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

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

निष्कर्ष

इस परियोजना से पहले, मुझे परीक्षणों के साथ कोड के 100% कवरेज का लक्ष्य निर्धारित नहीं करना था। मुझे 10 घंटे के विकास में एक कामकाजी आवेदन मिल सकता है, लेकिन मुझे 95% कवरेज तक पहुंचने में 20-30 घंटे लगे। एक छोटे से उदाहरण का उपयोग करते हुए, मुझे यह पता चला कि कोड कवरेज का मूल्य इसकी गुणवत्ता को कैसे प्रभावित करता है, और इसे बनाए रखने में कितना प्रयास होता है।

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

आप इसके बारे में निम्नलिखित सामग्रियों और उन पर टिप्पणियों में पढ़ सकते हैं:

स्पॉइलर

"कोटिंग" शब्द का उपयोग लगभग 20 बार किया जाता है। मैं माफी चाहता हूँ।

एक उदाहरण के रूप में एसक्यूएल-डम्पर का उपयोग करके गो में परीक्षणों के साथ 100% कोड कवरेज के रास्ते पर