Node.js परियोजनाओं का परीक्षण। भाग 1. परीक्षण शरीर रचना और परीक्षण प्रकार

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



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

→ Node.js परियोजनाओं का परीक्षण। भाग 2. परीक्षण प्रदर्शन मूल्यांकन, निरंतर एकीकरण और कोड गुणवत्ता विश्लेषण

▍0। स्वर्णिम नियम: परीक्षण बहुत सरल और सीधे होने चाहिए

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

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

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

खंड 1. परीक्षणों का एनाटॉमी

▍1। अपने परीक्षण डिजाइन करें ताकि रिपोर्ट आपको बताए कि क्या परीक्षण किया जा रहा है, किस परिदृश्य में है, और परीक्षण से क्या अपेक्षित है

सिफारिशें

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

1. वास्तव में क्या परीक्षण किया जा रहा है? उदाहरण के लिए, ProductsService.addNewProduct विधि।
2. परीक्षण किस परिस्थिति में और किस परिस्थिति में आयोजित किया गया है? उदाहरण के लिए, सिस्टम की प्रतिक्रिया ऐसी स्थिति में जांच की जाती है जहां माल की कीमत विधि को पारित नहीं किया गया है।
3. अपेक्षित परीक्षा परिणाम क्या हैं? उदाहरण के लिए, एक समान स्थिति में, सिस्टम एक नए उत्पाद को जोड़ने की पुष्टि करने से इनकार कर देता है।

सिफारिशों से विचलन का परिणाम

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

सही दृष्टिकोण

परीक्षण की जानकारी में तीन जानकारी होती है।

 //1.   describe('Products Service', function() { //2.  describe('Add new product', function() {   // 3. ,       it('When no price is specified, then the product status is pending approval', ()=> {     const newProduct = new ProductService().add(...);     expect(newProduct.status).to.equal('pendingApproval');   }); }); }); 

सही दृष्टिकोण

परीक्षण रिपोर्ट उत्पाद आवश्यकताओं के एक बयान युक्त एक दस्तावेज जैसा दिखता है।

यहां बताया गया है कि यह विभिन्न स्तरों पर कैसा दिखता है।


उत्पाद की आवश्यकता दस्तावेज़, टेस्ट नामकरण, परीक्षण के परिणाम

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

▍2। वर्णन करें कि आप उत्पाद भाषा में परीक्षण से क्या उम्मीद करते हैं: बीडीडी-शैली के बयानों का उपयोग करें

सिफारिशें

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

सिफारिशों से विचलन का परिणाम

यदि आप ऊपर वर्णित सिफारिशों का पालन नहीं करते हैं, तो यह इस तथ्य के साथ समाप्त हो जाएगा कि विकास टीम के सदस्य कम परीक्षण लिखेंगे और .skip() पद्धति का उपयोग करके कष्टप्रद चेक को छोड़ .skip() ।

गलत दृष्टिकोण

इस परीक्षण के पाठक को केवल परीक्षण में यह समझने के लिए कि केवल परीक्षण में परीक्षण किया जा रहा है, बल्कि लंबे समय तक आवश्यक कोड की पूरी तरह से समीक्षा करनी होगी।

 it("When asking for an admin, ensure only ordered admins in results" , ()={   //,       — "admin1"  "admin2",   "user1"   const allAdmins = getUsers({adminOnly:true});   const admin1Found, adming2Found = false;   allAdmins.forEach(aSingleUser => {       if(aSingleUser === "user1"){           assert.notEqual(aSingleUser, "user1", "A user was found and not admin");       }       if(aSingleUser==="admin1"){           admin1Found = true;       }       if(aSingleUser==="admin2"){           admin2Found = true;       }   });   if(!admin1Found || !admin2Found ){       throw new Error("Not all admins were returned");   } }); 

सही दृष्टिकोण

आप इस परीक्षण को सचमुच एक नज़र में समझ सकते हैं।

 it("When asking for an admin, ensure only ordered admins in results" , ()={   //,        const allAdmins = getUsers({adminOnly:true});     expect(allAdmins).to.include.ordered.members(["admin1" , "admin2"]) .but.not.include.ordered.members(["user1"]); }); 

▍3। विशेष प्लगिन का उपयोग करके परीक्षण कोड अस्तर करना

सिफारिशें

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

सिफारिशों से विचलन का परिणाम

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

गलत दृष्टिकोण

परीक्षण परिदृश्य त्रुटियों से भरा है, जो, सौभाग्य से, लिंटर का उपयोग करके पता लगाया जा सकता है।

 describe("Too short description", () => { const userToken = userService.getDefaultToken() // *error:no-setup-in-describe, use hooks (sparingly) instead it("Some description", () => {});//* error: valid-test-description. Must include the word "Should" + at least 5 words }); it.skip("Test name", () => {// *error:no-skipped-tests, error:error:no-global-tests. Put tests only under describe or suite expect("somevalue"); // error:no-assert }); it("Test name", () => {*//error:no-identical-title. Assign unique titles to tests }); 

▍4। ब्लैक बॉक्स विधि के लिए छड़ी - केवल सार्वजनिक तरीकों का परीक्षण करें

सिफारिशें

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

सिफारिशों से विचलन का परिणाम

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

गलत दृष्टिकोण

यह परीक्षण इस तरह की जाँच के लिए किसी विशेष कारण के लिए एक वर्ग के आंतरिक तंत्र का परीक्षण करता है।

 class ProductService{ //      //     ,      calculateVAT(priceWithoutVAT){   return {finalPrice: priceWithoutVAT * 1.2};   //           } //  getPrice(productId){   const desiredProduct= DB.getProduct(productId);   finalPrice = this.calculateVATAdd(desiredProduct.price).finalPrice; } } it("White-box test: When the internal methods get 0 vat, it return 0 response", async () => {   //       VAT,      .  ,   ,        expect(new ProductService().calculateVATAdd(0).finalPrice).to.equal(0); }); 

▍5। उपयुक्त बैकअप ऑब्जेक्ट्स चुनें: मॉब्स से बचें, स्टब्स और जासूसों को प्राथमिकता दें

सिफारिशें

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

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

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

सिफारिशों से विचलन का परिणाम

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

गलत दृष्टिकोण

यह उदाहरण अनुप्रयोग के आंतरिक तंत्र के परीक्षण पर केंद्रित एक नकली वस्तु दिखाता है।

 it("When a valid product is about to be deleted, ensure data access DAL was called once, with the right product and right config", async () => {   //,        const dataAccessMock = sinon.mock(DAL);   // ,           dataAccessMock.expects("deleteProduct").once().withArgs(DBConfig, theProductWeJustAdded, true, false);   new ProductService().deletePrice(theProductWeJustAdded);   mock.verify(); }); 

सही दृष्टिकोण

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

 it("When a valid product is about to be deleted, ensure an email is sent", async () => {   //,        const spy = sinon.spy(Emailer.prototype, "sendEmail");   new ProductService().deletePrice(theProductWeJustAdded);   //  .       ? ,               (  ) }); 

▍6। परीक्षण के दौरान, "फू" जैसी किसी चीज़ तक सीमित न होकर यथार्थवादी इनपुट का उपयोग करें

सिफारिशें

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

सिफारिशों से विचलन का परिणाम

अपने विकास के दौरान एक परियोजना का परीक्षण करते समय, सभी परीक्षणों को केवल तभी पारित किया जा सकता है जब उन्हें "फू" जैसी अवास्तविक डेटा का उपयोग किया जाता है। लेकिन उत्पादन में, सिस्टम उस स्थिति में विफल हो जाएगा जहां हैकर उसे @3e2ddsf . ##' 1 fdsfds . fds432 AAAA जैसी कुछ चीज़ देता है @3e2ddsf . ##' 1 fdsfds . fds432 AAAA @3e2ddsf . ##' 1 fdsfds . fds432 AAAA @3e2ddsf . ##' 1 fdsfds . fds432 AAAA

गलत दृष्टिकोण

सिस्टम इन परीक्षणों को सफलतापूर्वक केवल इसलिए पास करता है क्योंकि वे अवास्तविक डेटा का उपयोग करते हैं।

 const addProduct = (name, price) =>{ const productNameRegexNoSpace = /^\S*$/;//  if(!productNameRegexNoSpace.test(name))   return false;// , -   ,  .     //  -    return true; }; it("Wrong: When adding new product with valid properties, get successful confirmation", async () => {   // "Foo",    ,    ,    false   const addProductResult = addProduct("Foo", 5);   expect(addProductResult).to.be.true;   // :     - ,     //         }); 

सही दृष्टिकोण

यह वास्तविक डेटा के समान यादृच्छिक डेटा का उपयोग करता है।

 it("Better: When adding new valid product, get successful confirmation", async () => {   const addProductResult = addProduct(faker.commerce.productName(), faker.random.number());   //   : {'Sleek Cotton Computer',  85481}   expect(addProductResult).to.be.true;   //  ,         ,    .   //     ,    ! }); 

▍ ▍। गुण-आधारित परीक्षण का उपयोग करके कई इनपुट संयोजनों का उपयोग कर टेस्ट सिस्टम

सिफारिशें

आमतौर पर, परीक्षण इनपुट डेटा के छोटे सेट का उपयोग करते हैं। यहां तक ​​कि अगर वे वास्तविक डेटा से मिलते-जुलते हैं (हमने पिछले अनुभाग में इस बारे में बात की थी), ऐसे परीक्षण केवल जांच इकाई के इनपुट के संभावित संयोजनों की बहुत सीमित संख्या को कवर करते हैं। उदाहरण के लिए, यह इस तरह दिख सकता है: (method('', true, 1), method("string" , false" , 0)) । समस्या यह है कि उत्पादन एपीआई में, जिसे पांच मापदंडों के साथ कहा जाता है, इसे प्राप्त कर सकते हैं उनके संयोजनों के हजारों विभिन्न प्रकारों के इनपुट, जिनमें से एक विफलता हो सकती है (यह उचित होगा कि आप यहां फ़ेसिंग को याद करें ) । यदि आप एक भी परीक्षण लिख सकते हैं जो स्वचालित रूप से अपने इनपुट के 1000 संयोजनों के लिए एक निश्चित विधि की जांच करता है और पाता है कि कौन सा है। क्या विधि गलत तरीके से प्रतिक्रिया करती है? संपत्ति सत्यापन के आधार पर परीक्षण वास्तव में क्या है ऐसी स्थिति में हमें, इस परीक्षण मॉड्यूल चेकों के पाठ्यक्रम में, इनपुट डेटा है, जो कुछ कीड़े पाने की संभावना बढ़ जाती है की सभी संभव संयोजनों के साथ बुला उपयोगी है अर्थात्।। मान लीजिए कि हमें एक विधि है addNewProduct(id, name, isDiscount) , और पुस्तकालय परीक्षण करना, इसे संख्यात्मक, स्ट्रिंग और तार्किक प्रकार के मापदंडों के कई संयोजनों के साथ कहता है, उदाहरण के लिए - (1, "iPhone", false) , (2, "Galaxy", true) । सामान्य परीक्षण निष्पादन वातावरण (मोचा, जेस्ट, और इसी तरह) का उपयोग करके संपत्ति सत्यापन के आधार पर परीक्षण करना संभव है और विशेष पुस्तकालयों जैसे जेएस-सत्यापन या टेस्टचेक का उपयोग करना (इस पुस्तकालय में बहुत अच्छा प्रलेखन है)।

सिफारिशों से विचलन का परिणाम

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

सही दृष्टिकोण

मोचा-टेस्टचेक लाइब्रेरी का उपयोग करके कई इनपुट विकल्पों का परीक्षण।

 require('mocha-testcheck').install(); const {expect} = require('chai'); const faker = require('faker'); describe('Product service', () => { describe('Adding new', () => {   //  100         check.it('Add new product with random yet valid properties, always successful',     gen.int, gen.string, (id, name) => {       expect(addNewProduct(id, name).status).to.equal('approved');     }); }) }); 

▍8। टेस्ट कोड के लिए आत्मनिर्भर होना, बाहरी एड्स और अमूर्त को कम करना

सिफारिशें

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

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

सिफारिशों से विचलन का परिणाम

, 4 , 2 , ? ! , , .

. ?

 test("When getting orders report, get the existing orders", () => {   const queryObject = QueryHelpers.getQueryObject(config.DBInstanceURL);   const reportConfiguration = ReportHelpers.getReportConfig();//   ?        userHelpers.prepareQueryPermissions(reportConfiguration);//  ?         const result = queryObject.query(reportConfiguration);   assertThatReportIsValid();//  ,           -    expect(result).to.be.an('array').that.does.include({id:1, productd:2, orderStatus:"approved"});   //      ?        }) 

सही दृष्टिकोण

, .

 it("When getting orders report, get the existing orders", () => {   // ,           const orderWeJustAdded = ordersTestHelpers.addRandomNewOrder();   const queryObject = newQueryObject(config.DBInstanceURL, queryOptions.deep, useCache:false);   const result = queryObject.query(config.adminUserToken, reports.orders, pageSize:200);   expect(result).to.be.an('array').that.does.include(orderWeJustAdded); }) 

▍9. :

सिफारिशें

, , , , . . , ( ) . — , ( , ). — , , , , . , , . — , , , , ( , , , ).

सिफारिशों से विचलन का परिणाम

, . . . . , , , .

. , .

 before(() => { //       .   ? - ,  -   json-. await DB.AddSeedDataFromJson('seed.json'); }); it("When updating site name, get successful confirmation", async () => { // ,  ,  "Portal", ,           const siteToUpdate = await SiteService.getSiteByName("Portal"); const updateNameResult = await SiteService.changeName(siteToUpdate, "newName"); expect(updateNameResult).to.be(true); }); it("When querying by site name, get the right site", async () => { // ,  ,  "Portal", ,           const siteToCheck = await SiteService.getSiteByName("Portal"); expect(siteToCheck.name).to.be.equal("Portal"); //!      :[ }); 

सही दृष्टिकोण

, , .

 it("When updating site name, get successful confirmation", async () => { //           const siteUnderTest = await SiteService.addSite({   name: "siteForUpdateTest" }); const updateNameResult = await SiteService.changeName(siteUnderTest, "newName"); expect(updateNameResult).to.be(true); }); 

▍10. , . expect

सिफारिशें

, , try-catch-finally catch . , , , .

Chai, expect(method).to.throw . Jest: expect(method).toThrow() . , . , , .

सिफारिशों से विचलन का परिणाम

, , , .

, try-catch .

 it("When no product name, it throws error 400", async() => { let errorWeExceptFor = null; try { const result = await addNewProduct({name:'nest'});} catch (error) { expect(error.code).to.equal('InvalidInput'); errorWeExceptFor = error; } expect(errorWeExceptFor).not.to.be.null; //    ,         //  ,     null,       }); 

सही दृष्टिकोण

expect , , .

 it.only("When no product name, it throws error 400", async() => { expect(addNewProduct)).to.eventually.throw(AppError).with.property('code', "InvalidInput"); }); 

▍11. ,

सिफारिशें

. , (smoke test), -, , . - . , , , #cold , #api , #sanity . . , Mocha -g ( --grep ).

सिफारिशों से विचलन का परिणाम

, , , , , , . .

सही दृष्टिकोण

#cold-test , . , -, , — .

 //    ( ,    ),     // ,        //   describe('Order service', function() { describe('Add new order #cold-test #sanity', function() {   it('Scenario - no currency was supplied. Expectation - Use the default currency #sanity', function() {     //-    }); }); }); 

▍12.

सिफारिशें

, Node.js-. , , Node.js .

TDD — , , . , . , , Red-Green-Refactor . , - , , , , , . , . ( — , , ).

सिफारिशों से विचलन का परिणाम

— , . .

2.

▍13. ,

सिफारिशें

, , 10 , . , . , . , (, ), , , , ? - ?

, . , 2019 , , TDD, — , . , , , . , IoT-, , , - Kafka RabbitMQ, . - , , , . , , , , ? (, , Alexa) , , .

, ( ). , , , , , , . , , - API — Consumer-Driven Contracts . , , , , . , , , , , . , , .

, TDD . , TDD , . , , , .

सिफारिशों से विचलन का परिणाम

— ( ), .

सही दृष्टिकोण

. . , , Node.js, .

▍14. ,

सिफारिशें

. — . , , . , , - , , - ? , . , : TDD, — .

«». API, - , (, , , , , ). , , , (, ). , , , , , , .

सिफारिशों से विचलन का परिणाम

, , , , 20.

सही दृष्टिकोण

supertest , API, Express, .


API, Express

▍15. , API, Consumer-Driven Contracts

सिफारिशें

, , , , . , , - , , , - . «-22» : . , , . , Consumer-Driven Contracts PACT .

. . PACT , ( «»). , , PACT, , , . , , , , .

सिफारिशों से विचलन का परिणाम

.

सही दृष्टिकोण

Consumer-Driven Contracts

, , B , . B .

▍16.

सिफारिशें

(middleware) - , , - , Express-. . , , . , , JS- {req,res} . , «» (, Sinon ) , {req,res} . , , , . node-mock-http , , , . , , HTTP-, -.

सिफारिशों से विचलन का परिणाम

Express .

सही दृष्टिकोण

Express-.

 // ,     const unitUnderTest = require('./middleware') const httpMocks = require('node-mocks-http'); //  Jest,     Mocha    describe()  it() test('A request without authentication header, should return http status 403', () => { const request = httpMocks.createRequest({   method: 'GET',   url: '/user/42',   headers: {     authentication: ''   } }); const response = httpMocks.createResponse(); unitUnderTest(request, response); expect(response.statusCode).toBe(403); }); 

▍17.

सिफारिशें

, , , , , , . , , - . , , , ( , , ), , ( — ) . , : SonarQube ( 2600 GitHub) Code Climate ( 1500 ).

सिफारिशों से विचलन का परिणाम

, , . . , .

सही दृष्टिकोण

Code Climate.


Code Climate

▍18. , Node.js

सिफारिशें

, , . , , , - , . , - , , , , ? , , ? , API ?

Netflix - . , , , , . , - — Chaos Monkey . , , , . Kubernetes — kube-monkey . , Node.js? , , , V8 1.7 . . node-chaos , -.

सिफारिशों से विचलन का परिणाम

, , , .

सही दृष्टिकोण

npm- chaos-monkey , Node.js.


chaos-monkey

परिणाम

, Node.js-. , . .

प्रिय पाठकों! - ?