💃🏾 🍽️ 💍 Node.js: जनरल-पर्पस लाइब्रेरी डेवलपमेंट टेक्नोलॉजीज का अवलोकन 🤛🏿 🏌️ 🧙🏼

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

परीक्षण ( चमेली_नोड )
परीक्षण के साथ कोड कवरेज ( इस्तानबुल )
पुस्तकालय के हिस्से की ग्राहक सभा ( ब्राउजर करें )
स्वचालित ग्राहक परीक्षण ( प्रेत )
मेमोरी लीक ( मेमवॉच ) के लिए खोजें

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

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

पीछे हटना

सभी उदाहरणों में ग्रंट बिल्ड सिस्टम के लिए कोड होगा। यदि आप पहले से ही परिचित नहीं हैं कि यह क्या है, तो यह करने का समय है, अन्यथा सफलता के रास्ते पर आप नियमित रूप से कंसोल पर ठोकर खाएंगे। यदि आप "उन्नत" हैं, तो टिप्पणियों में "गल्प" न चिल्लाएं, अपने बिल्ड सिस्टम के लिए कोड को अपनाना आपके लिए कोई समस्या नहीं होगी।

परीक्षण

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

कुछ ऐतिहासिक क्षण जिनमें मैंने पहले ही चमेली का उपयोग किया है।
कोड पुन: उपयोग के रूप में Node.js और एक पुस्तकालय द्वारा ब्राउज़र का समर्थन।
पुस्तकालय की परिपक्वता, और परिणामस्वरूप, विभिन्न उपकरणों में एकीकरण की उपलब्धता।

स्थापना

npm install grunt-jasmine-node --save-dev

Gruntfile.js कॉन्फ़िगरेशन

 jasmine_node: { options: { forceExit: true, match: '.', matchall: false, extensions: 'js', specFolders : ['./spec/'] }, all: ['spec/'] }

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

टेस्ट कवरेज विश्लेषण कोड

कोई अच्छा कारण नहीं है कि लाइब्रेरी कोड को परीक्षणों में 100% कवर नहीं किया जाना चाहिए। कोड में प्रत्येक शर्त को एक परीक्षण द्वारा कवर किया जाना चाहिए, अन्यथा आप अप्रत्याशित व्यवहार का सामना करेंगे या कोड लिखेंगे जो कभी भी काम नहीं करता है। यदि लाइब्रेरी में 100% आत्मविश्वास के लिए परीक्षण द्वारा कोड को कवर नहीं किया गया है। परीक्षणों के साथ कोड की कवरेज की जांच करने के लिए, आपको istanbul लाइब्रेरी का उपयोग करने की आवश्यकता है। "नग्न" रूप में अपने आप में इतनबुल हमारे लिए दिलचस्प नहीं है। इसे टेस्ट रन सिस्टम में एकीकृत किया जाना चाहिए। यह ग्रंट-जैस्मीन-नोड-कवरेज मॉड्यूल क्या करता है। स्रोत कोड कवरेज के आरामदायक विश्लेषण के लिए यह आपको html-form (और न केवल) में एक रिपोर्ट प्राप्त करने की अनुमति देगा।

स्थापना

 npm install grunt-jasmine-node-coverage --save-dev

चूंकि हम चमेली को इतनबुल के साथ एकीकृत कर रहे हैं, इसलिए आपको चमेली के विन्यास को बदलना होगा

 jasmine_node: { coverage: {}, //     options: { forceExit: true, match: '.', matchall: false, extensions: 'js', specFolders : ['./spec/'] }, all: ['spec/'] }

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

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

पुस्तकालय भाग के ग्राहक विधानसभा

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

स्थापना

 npm install grunt-browserify --save-dev

विन्यास

 browserify: { dist: { files: { 'dist/my-library.js': ['lib/my-library.js'] } } }

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

स्वचालित ग्राहक परीक्षण

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

 browserify: { dist: { files: { 'dist/my-library.js': ['lib/my-library.js'], 'dist/my-library.spec.js': ['spec/my-library.spec.js'] } } }

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

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

स्थापना

 npm install phantomjs --save-dev

का प्रयोग करें। हमारे TestRunner.html को चलाने और परीक्षण के परिणाम प्राप्त करने के लिए, आपको निम्नलिखित की आवश्यकता है:

1. एक n.js विनिर्देशन फ़ाइल लिखें जो phantom.js लॉन्च करेगी (चमेली में स्वचालित रूप से चलाने के लिए)

2. प्रेतों के लिए एक स्क्रिप्ट लिखिए जो निम्नलिखित कार्य करेगा:

काम खत्म करने के लिए चमेली की प्रतीक्षा करें।
परिणामी पृष्ठ के डोम को पार्स करें और पता करें कि कितने परीक्षण गिर गए। (संदेह है कि डोम को पार्स करने से बेहतर तरीका है)।
फैंटमज को बंद करो।

3. परीक्षणों की विफलता के बारे में संदेशों के लिए प्रेत के परिणाम का विश्लेषण करना।

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

प्रेरणा के लिए, आप उपरोक्त पुस्तकालय में पहले से लागू स्क्रिप्ट को देख सकते हैं, जिसके विकास के अनुभव पर यह लेख दिखाई दिया।

प्रेरणा के लिए फाइलों का लिंक

1. फैंटमज के लिए आधिकारिक चमेली परीक्षण स्वचालन स्क्रिप्ट ।

2. असली युक्ति फ़ाइल । पहला और तीसरा अंक।

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

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

मेमोरी लीक के लिए खोजें

यहां तक कि अगर आपने सब कुछ सही ढंग से किया है और आपका कोड 100% परीक्षण किया गया है, तो यह आपको कोई गारंटी नहीं देता है कि पुस्तकालय "लीक" नहीं करता है। और अगर, वस्तुनिष्ठ कारणों से, उन्होंने इसे ब्राउज़र में स्कोर किया, तो "द्रव" सर्वर सेवा का अनुमान लगाना कठिन नहीं है - यह एक विफलता है।

मेमोरी लीक की खोज के लिए एक कम काम करने वाला उपकरण जो मुझे मिल सकता है वह है मेमोवच ( हब पर लेख )। दुर्भाग्य से, मैं इसके उपयोग को स्वचालित नहीं कर सका। परिणामों की कोई स्थिरता नहीं है (या मुझे कुछ याद नहीं है)।

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

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

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

Node.js: जनरल-पर्पस लाइब्रेरी डेवलपमेंट टेक्नोलॉजीज का अवलोकन