सभी को नमस्कार, मेरा नाम यारोस्लाव एस्टाफ़िएव है, और आज मैं ReactJS के परीक्षण में एक निर्देशित दौरे का संचालन करना चाहूंगा। मैं विशिष्ट पुस्तकालयों का उपयोग करके वेब अनुप्रयोगों के परीक्षण की जटिलता में नहीं उतरूंगा ("केवल बुरे कोड का परीक्षण करना मुश्किल है"), बदले में मैं आपके क्षितिज को विविधता लाने का प्रयास करूंगा। तो इस लेख में, रिएक्ट एक परीक्षण के दृष्टिकोण को एक साथ रखने के लिए एक अवसर है, एक शुरुआती बिंदु जो हिपस्टर्स और प्रौद्योगिकी को जोड़ता है। यहां तक कि यह भी कहना सही होगा कि हम रिएक्टजेस (और केवल नहीं) पर चित्रण के साथ सामान्य रूप से परीक्षण के सिद्धांतों के बारे में बात करेंगे।
यदि आप अपने आप को एक परीक्षण गुरु मानते हैं -
लेख के पहले भाग को छोड़ दें , तो यह परीक्षण के मूल सिद्धांतों के बारे में है। यदि दूसरा भाग आपके लिए कुछ नया नहीं बताता है, तो काम करने के लिए हमारे पास आओ और सिखाएं कि कैसे।
यदि परिचय ने सिंथेसिस के हमले का कारण नहीं बनाया, तो बिल्ली का स्वागत करें।
यूनिट परीक्षण
यूनिट जेस्ट जावास्क्रिप्ट परीक्षण के लिए एक पुस्तकालय है। इसे पसंद न करें -
दूसरा लें , लेकिन फिर
अवा बेहतर है। यहां सब कुछ सरल है: जादू बटन पर क्लिक करें और सुनिश्चित करें कि "0" से एक निश्चित मूल्य "1" में बदल गया है:
import React from "react" import { MyButton } from "../src/components/dummy/myButton" import renderer from "react-test-renderer" test("MyButton has onPress fn", () => { let x = 0 const instance = renderer .create(<MyButton onPress={() => x++} />) .getInstance() expect(instance.handlePress).toBeDefined() expect(x).toBe(0) instance.props.handlePress() expect(x).toBe(1) })
अब आपके पास जादू बटन का परीक्षण करने के लिए
सभी आवश्यक कौशल हैं । दुर्भाग्य से, ये कौशल वास्तविक जीवन से संबंधित नहीं हैं। प्रतिक्रिया घटक इतनी अच्छी तरह से अछूता नहीं हो सकता है, और अलगाव इकाई परीक्षण के मुख्य सिद्धांतों में से एक है। किसी भी तरह, सभी घटकों को हटाने के लिए आवश्यक है जो किसी भी तरह परीक्षण किए गए अपवाद के साथ रेंडर विधि में भाग लेते हैं। और एक समाधान है: स्मार्ट लोग इसके लिए mockAPI के साथ आए।
मॉक का सार सरल है: जो हमारा नहीं है वह
मॉक / स्टब / फेक / डमी / स्पाई आदि है। हम उस तरीके का "अनुकरण" करते हैं, जिसके लिए हमें एक घटक के वास्तविक व्यवहार की आवश्यकता होती है, जिसमें जटिल तर्क हो सकते हैं, पूर्व-तैयार परीक्षण डेटा पर और यह विश्वास है कि सभी उत्सर्जित घटक पूरी तरह से काम करते हैं यदि सही पैरामीटर उनके लिए इनपुट हैं।
जेस्ट के लिए एक
जेस्ट- भ्रूण
-मॉक लाइब्रेरी है, इसमें आप विश्व स्तर पर मोकी को परिभाषित कर सकते हैं। यदि आप इस विकल्प को पसंद नहीं करते हैं, तो आप प्रत्येक घटक को अलग से परीक्षण में "गीला" कर सकते हैं।
एक ही इनपुट पर
एक शुद्ध कार्य हमेशा एक ही उत्तर देता है। तदनुसार, यदि हमारे व्यावसायिक तर्क में घटकों के "साफ नहीं" फ़ंक्शन / घटक हैं, तो यूनिट परीक्षणों में उन्हें "साफ़" करने की आवश्यकता होगी (लेकिन इकाई परीक्षणों के लिए यह नियम हमेशा सही नहीं है)। एक क्लासिक उदाहरण एक प्रतिक्रिया घटक है जो आपके द्वारा आवश्यक प्रारूप में वर्तमान तिथि और समय प्रदर्शित करता है, हर बार जब आप परीक्षण चलाते हैं, तो तारीख अलग होगी और आप सही इकाई परीक्षण लिखने में सक्षम नहीं होंगे। उन सभी के लिए जो असहमत हैं, आप उदाहरण को जटिल कर सकते हैं जहां आपके घटक को सापेक्ष प्रारूप में दिनांक प्रदर्शित करनी चाहिए और उन तिथियों को उजागर करना चाहिए
जो वर्तमान तिथि से एक
वर्ष से अधिक पुरानी हैं।
तदनुसार, यदि आपके पास गतिशील चीजें हैं जो समय / मौसम / दबाव पर निर्भर करती हैं, तो मॉक आपको आवश्यक कॉल को फिर से परिभाषित करेगा ताकि तीसरे पक्ष के कारकों पर निर्भरता न हो। इस प्रकार, आपको एक गिरी हुई परीक्षा को पकड़ने के लिए
29 फरवरी का इंतजार करने की आवश्यकता नहीं है।
यूनिट टेस्ट नियम
ऊपर वर्णित समस्याएं और उन्हें हल करने के तरीके परीक्षण के लिए एक अनौपचारिक दृष्टिकोण पर प्रयास हैं: प्रत्येक परीक्षण जैसा चाहता है वैसे चलता है। मेरी राय में,
यूनिट परीक्षण के तीन महत्वपूर्ण नियमों का अनुपालन पर्याप्त है:
- यह सिद्धांत कि मनुष्य के कार्य स्वतंत्र नहीं होते
- इन्सुलेशन
- बाहरी कारकों से स्वतंत्रता
- सामान्य ज्ञान
नियम एक: सभी परीक्षण निर्धारक होना चाहिए। अगर मैंने विंडोज पर एक परीक्षण लिखा है, तो एक मैक पर इसे भी शुरू करना चाहिए और उसी परिणाम का उत्पादन करना चाहिए। विंडोज डेवलपर्स भूल जाते हैं कि निक्स सिस्टम पर फ़ाइल नाम केस संवेदनशील हैं। और आप भाग्यशाली हैं यदि
परीक्षण सीआई के ढांचे के भीतर आते हैं, और उत्पादन में आवेदन नहीं ।
अगला नियम अलगाव है। हम सभी गैर-परीक्षण घटकों को गीला करते हैं। यदि यह करना मुश्किल है, तो यह समय के लिए रिफ्लेक्टर है।
अंतिम लेकिन कम से कम: यदि कोई डेटा है जो आपके एप्लिकेशन को रनटाइम में प्राप्त होता है, तो उन्हें भी नस्ट होने की आवश्यकता है। यह एक लोकल, विंडो साइज, डेट फॉर्मेट, फ्लोटिंग पॉइंट नंबर फॉर्मेट आदि हो सकता है।
एकीकरण परीक्षण
जब एकीकरण परीक्षण लिखना शुरू किया जाता है, तो मेरी राय में, एक खुला प्रश्न, और प्रत्येक व्यक्तिगत टीम / उत्पाद में निर्णय को आंतरिक कारकों में लेना चाहिए।
आप एक औपचारिक तरीका अपना सकते हैं:
80% की
इकाई परीक्षण कवरेज प्राप्त करें (खराब लिखित परीक्षणों की समीक्षा नहीं की जानी चाहिए / परीक्षणों द्वारा कवर किए जाने के लिए केवल नए या परिवर्तित कोड की आवश्यकता होती है), फिर एक पूर्ण ऑडिट करें और सभी त्रुटियों के लिखित परीक्षण का परीक्षण करें जिसमें विशिष्ट त्रुटियों का विश्लेषण हो, लेखन परीक्षणों के लिए आंतरिक नियमों को औपचारिक बनाएं और प्रति वर्ष इस तरह के छापे मारते हैं। यदि आपके यूनिट परीक्षणों के ऊपर वर्णित सभी क्रियाओं के बाद भी कोड कवरेज 80% + है, तो आपके पास एक परिपक्व टीम है, या आप बस अपने कोड / परीक्षणों के लिए महत्वपूर्ण नहीं हैं। यदि कोड कवरेज कम हो गया है, तो आपको फिर से 80% कवरेज प्राप्त करने की आवश्यकता है और एकीकरण परीक्षण लिखने के लिए आगे बढ़ें। आप औपचारिक रूप से कम आ सकते हैं और बस सामान्य ज्ञान द्वारा निर्देशित हो सकते हैं: उदाहरण के लिए, प्रत्येक बग के लिए जो n बार खेला गया है, एक परीक्षण लिखें या किसी और चीज़ के साथ आएं, उदाहरण के लिए, एक सिक्का टॉस करें।
दूसरा खुला सवाल:
क्या परीक्षणों को एकीकरण माना जाता है ? शायद इसे अनुत्तरित छोड़ दें।
एकीकरण परीक्षणों में, हम एक घटक के काम का परीक्षण नहीं करते हैं, लेकिन एक गुच्छा में कई घटक होते हैं। कोई नियम नहीं हैं, लेकिन सामान्य ज्ञान आपको बताता है:
- यह परीक्षण न करें कि यह कैसे प्रदान किया जाता है, इसे कहाँ कहा जाता है, और जब यह सब समाप्त हो जाएगा;
- रिएक्टजेएस के काम का परीक्षण न करें, अगर यह काम नहीं करता है, तो कुछ भी आपकी मदद नहीं करेगा;
- परीक्षण न करें कि राज्य मशीन कैसे काम करती है;
- व्यावसायिक तर्क / डेटा मॉडल / सीमा रेखा की स्थिति / कुछ ऐसा है जो अक्सर टूट जाता है।
ऐसे परीक्षणों में, आपको विवरण में नहीं जाना चाहिए। वे ध्यान से लंबे समय तक चलते हैं और उन्हें लिखना भी अधिक कठिन है, इसलिए आपको आवेदन के तर्क में हर छोटे मामले को दूर नहीं करना चाहिए। यह बुनियादी ढांचे के किराये के मामले में महंगा है, और विकास और स्क्रिप्ट निष्पादन के समय के मामले में लंबा है। कोई इस दिनचर्या पर अपना जीवन बिताएगा, और
उपयोगकर्ता प्रबंधक दुखी होगा , और नई सुविधाओं की प्रतीक्षा
करेगा , और ...
एक और कारण है कि आपको सब कुछ परीक्षण करने की कोशिश नहीं करनी चाहिए झूठी सुरक्षा (मैंने ऊपर दिए गए सबसे महत्वपूर्ण बिंदुओं को लिखने की कोशिश की है)। प्रत्येक टीम को पहली और दूसरी तरह की गलतियों के बारे में पढ़ना चाहिए, न्यूमैन-पीयरसन लेम्मा और टीम में स्वीकार किए गए पैसे, तोते या सच्चाई के अन्य माप के संदर्भ में उनके जोखिमों का आकलन करें।
लेकिन इस नियम के अपवाद हैं, साथ ही साथ किसी भी अन्य के लिए।
जो कुछ ऊपर कहा गया है उसे भूल जाओ :
- जब गतिशील निर्भरता का परीक्षण। जब आप नहीं जानते कि रनटाइम में कौन सा कंपोनेंट आएगा, तो आप इसे रेंडर कर देते हैं, लेकिन यह नहीं आ सकता है। आपको इसके लिए एक परीक्षण लिखने की भी आवश्यकता है, किसी ने सर्किट ब्रैकर को रद्द नहीं किया है। या तो गलत घटक जिसकी आपको उम्मीद थी, या एक टूटा घटक आ जाएगा। इसलिए, इस मामले में, हम एक एकीकरण परीक्षण लिखते हैं और प्रस्तुत करते हैं। हम जांचते हैं कि क्या सब कुछ काम करता है, अगर कुछ भी नहीं गिरता है।
- पिक्सेल सही (अच्छी तरह से, आप समझते हैं) के साथ, विकास को स्क्रीनशॉट को प्रस्तुत करना और अलग करना होगा, और हर बार घटक लाइब्रेरी को एक नए संस्करण में अपडेट किया जाता है - संदर्भ स्क्रीनशॉट को अपडेट करें। क्योंकि फिक्सिंग की तुलना में
नए डिजाइनर को काम पर रखना आसान है ।
स्नैपशॉट परीक्षण
सबसे सरल एकीकरण परीक्षण एक स्नैपशॉट है:
- हम एक घटक लेते हैं, इसे प्रस्तुत करते हैं
- रेंडर में हम कंसोल लिखते हैं। (इसे)
- कंसोल से संदर्भ डेटा की प्रतिलिपि बनाएँ
- तुलना
यदि आप थोड़ा भ्रमित होना चाहते हैं, तो मैं आपको
स्टोरीबुक लाइब्रेरी के साथ खेलने की सलाह देता हूं। यह स्नैपशॉट परीक्षणों के लिए एक पुस्तकालय है, जो
स्टाइलग्यूडिस्ट के विचार को
संयोग से
लपेटता है -
रिएक्टर घटकों के आधार पर अपना स्वयं का डिज़ाइन सिस्टम
बनाता है ।
स्नैपशॉट परीक्षण का पहला नियम:
कभी न बताएं, डेटा का परीक्षण करने का प्रयास करें । उन्हें हमेशा स्थिर, "लॉक अप" और स्वतंत्र होना चाहिए। दूसरा नियम: एक
टूटी हुई स्नैपशॉट परीक्षा का मतलब यह नहीं है कि सब कुछ खराब है । यदि वह लाल है - इस तथ्य से नहीं कि सब कुछ चला गया। लेआउट को समान बनाने के लिए कई विकल्प हैं, लेकिन DOM का पेड़ अलग था। इसलिए हम व्हाट्सएप, विशेषताओं, कुंजियों को अनदेखा करते हैं या हम परीक्षण नहीं करते हैं कि इतने समर्थन समय की आवश्यकता क्या है। या हम अपने हाथों से चिह्नित करते हैं कि क्या टूटा है, क्या नहीं है। हम टूटे हुए परीक्षणों को ठीक करते हैं और मॉक अपडेट मोड में स्टोरीबुक को पुनरारंभ करते हैं - वह मोड जिसमें परीक्षण घटकों को प्रस्तुत करेगा और स्नैपशॉट को अपेक्षित स्थिति में संदर्भ मूल्य के रूप में सम्मिलित करेगा।
xState और React Automata
ReactJS एक मुश्किल काम है। ऐसा लगता है कि पुस्तकालय अच्छा है। मैंने तीन घटक बनाए - एक वर्ग: और राज्य मशीन काम करती है और कोड सुंदर है। फिर आप छह महीने के लिए ReactJS पर लिखते हैं, आप कोड को देखते हैं - किसी प्रकार की बकवास। आप यह नहीं समझ पा रहे हैं कि कहाँ बैसाखी, कहाँ मार्ग, कहाँ राज्य, कहाँ कैश ... फिर आप सोचते हैं: ठीक है, जैसा कि फेसबुक सलाह देता है: मैं "hokeys", "हुक", कुछ और उपवास करता हूँ और अचानक अपने आप को यह सोचते हुए पकड़ लेता हूँ कि आप कैसे hh करते हैं। खरोंच से प्रतिक्रिया पर विकास के साथ एक परियोजना खोजने के प्रयासों में बर्बाद, ताकि निश्चित रूप
से सब कुछ खूबसूरती से करना सुनिश्चित हो ...
सब कुछ इतना जटिल है कि आमतौर पर यह समझना असंभव है कि यह कैसे काम करता है। और यह तब तक काम करता है जब तक कोई शिकायत नहीं करता। हम इसे ठीक करते हैं - और यह ठीक करता है, लेकिन चारों ओर टूट जाता है ... आउटपुट में से एक एक राज्य
मशीन है , आवेदन के निर्धारक राज्यों का एक सेट और उनके बीच संक्रमण की अनुमति है। और, जैसा कि वे संकीर्ण हलकों में कहते हैं, आपने प्रतिक्रिया पर नहीं लिखा था यदि आपने अपनी राज्य मशीन को नहीं मारा था।
यह
xState को याद रखने
योग्य है । यह जावास्क्रिप्ट के लिए एक नियतात्मक राज्य मशीन है।
आप xState पर बहुत अच्छा UI बना सकते हैं - संबंधित रिपोर्ट का लिंक
रिएक्ट ऑटोमेटा लाइब्रेरी के प्रलेखन में पाया जा सकता है। बदले में, रिएक्ट ऑटोमेटा वह लाइब्रेरी है जिसमें रिएक्टज में एक्सस्टेट को अनुकूलित किया गया था। इसके अलावा, वह
एक राज्य मशीन की स्थिति के लिए परीक्षण उत्पन्न करने में सक्षम है।
अगर हमारे पास पहला टिक सच है - हरी बत्ती चालू है। यदि दूसरा झूठा है, तो एक ग्रे कुत्ता खींचा जाता है, और रिएक्ट ऑटोमेटा इन मापदंडों के सभी चार संयोजनों के लिए परीक्षण उत्पन्न करता है और कुत्ते और बल्बों को मान्य करता है। सच है, कुछ बिंदु पर आप आधे परीक्षणों में कटौती करना चाहेंगे, लेकिन पहले तो आप बहुत खुश होंगे ... किसी भी मामले में, यह आपकी तरफ से परीक्षणों पर एक सुविधाजनक नज़र है, यह मुझे निर्धारक एनओएस के साथ परीक्षण के विचार की बहुत याद दिलाता है।
सरो
स्नैपशॉट के साथ, हम कम या ज्यादा पता लगा चुके हैं, आप एंड 2end की ओर जा सकते हैं। हमारे पास सभी उत्पाद आंतरिक हैं, इसलिए ऑन-प्रिमाइसेस समाधान हमारे एकमात्र विकल्प हैं। मुझे उम्मीद है कि आपके पास क्लाउड समाधान का उपयोग करने का अवसर है, तो
सरू जैसी चीज काम में आएगी।
पहले, आपने टेस्टिंग फ्रेमवर्क को चुना, जटिल XMLs की तुलना करने के लिए लाइब्रेरी, असेसमेंट, लाइब्रेरीज़ के लिए लाइब्रेरियाँ लीं। फिर हमने यह सब शुरू करने के लिए एक ड्राइवर और एक ब्राउज़र का चयन किया। उन्होंने शुरू किया और परीक्षणों का एक गुच्छा लिखा। यह सब बुनियादी ढांचे को खाता है, आपको डॉकटर में सब कुछ सामान करने की आवश्यकता है, फिर कुछ ऐसी चीज को पेंच करें जो कि गतिशीलता में परीक्षणों को देखता है, उनका विश्लेषण करता है, दिखाता है कि क्या गलत है ...
सरू लोगों ने यह सब तुम्हारे लिए किया। उन्होंने कई समस्याओं को हल किया:
एक कामकाजी वातावरण स्थापित करना, कोड लिखना, दौड़ना और परीक्षण लिखना। यदि परीक्षण टूट गया है, तो आप स्क्रीनशॉट को उजागर कर सकते हैं जो टूट गया है। सच है, यह मोबाइल फोन के लिए काम नहीं करता है, लेकिन वहां, उदाहरण के लिए,
डेटॉक्स है । यह, निश्चित रूप से, प्रवेश सीमा के दृष्टिकोण से कठिन है: आपको इसके लिए अपने आवेदन को दर्जी करना होगा, फ़ाइलों का एक गुच्छा फिर से लिखना होगा, आदि। लेकिन अगर आप चाहें तो यह संभव है।
नरम परीक्षण
वैकल्पिक प्रकार के परीक्षण हैं जिन्हें अच्छे परीक्षण भी नहीं कहा जा सकता है। मैं उन्हें सॉफ्ट टेस्ट कहता हूं। उदाहरण के लिए, लिंटर। वे मुख्य रूप से फ्रंट-एंड द्वारा उपयोग किए जाते हैं (और यहां तक कि, कभी-कभी, प्रेरणा javists के लिए नीचे आती है)। कई लिंटर हैं:
ESLint ,
JSHint ,
Prettier ,
Standard ,
Clinton । मैं
प्रीटीयर को सलाह देता
हूं: तेज, सस्ता, हंसमुख, कॉन्फ़िगर करने में आसान, बॉक्स से बाहर काम करता है ।
यदि आप भ्रमित होना चाहते हैं, तो आप ESLint को कॉन्फ़िगर कर सकते हैं। मैं आपको उनके लिए एक प्लगइन का एक उत्कृष्ट उदाहरण देता हूं: जब कोई ग्राहक आपके कोड में अश्लील अभिव्यक्तियों के साथ टिप्पणी पाता है, तो वह आमतौर पर शपथ लेता है। मुश्किल डेवलपर्स रूसी में टिप्पणियां करते हैं ताकि ग्राहक का अनुमान न हो। लेकिन ग्राहक ने अनुमान लगाया ... एक Google अनुवादक का उपयोग करें और उसे सब कुछ पता चला जो डेवलपर्स उसके बारे में सोचते हैं। स्थिति से बाहर का रास्ता अप्रिय है, संभवतः पैसे या ग्राहकों के नुकसान के साथ। इन मामलों के लिए,
आप हमेशा ESLint के लिए एक प्लगइन विकसित कर सकते हैं , जो आपके स्रोत कोड में "मूल रूसी" शब्द ढूंढता है और कहता है: "ओह, क्षमा करें, अपनी प्रतिबद्धता को अस्वीकार करें।"
जावास्क्रिप्ट में लिंटर्स की सुंदरता यह है कि उन्हें
एक पूर्व प्रतिबद्ध हुक पर रखा जा सकता है । व्यक्तिगत रूप से, मुझे यह पसंद नहीं है कि प्रिटियर इतिहास को संग्रहीत नहीं करता है (हालांकि, दूसरी ओर, यह तकनीकी ऋण को भी जमा नहीं करता है)। कोड के सांख्यिकीय विश्लेषण के दृष्टिकोण से, इस तरह के परीक्षण मनहूस हैं, क्योंकि आप परियोजना की गतिशीलता को नहीं देख सकते हैं, देखें कि कल से एक दिन पहले कितनी त्रुटियां थीं। सिद्धांत रूप में, यह समस्या
सोनारक्यूब में हल की
गई है , यह क्लाउड समाधान में भी है। यह एक सांख्यिकीय कोड विश्लेषक है जो रन के इतिहास को संग्रहीत करता है, दो दर्जन भाषाओं के साथ काम कर सकता है, यहां तक कि पीएचपी (जो स्थैतिक विश्लेषण के लोहे के हाथ की आवश्यकता नहीं है? :))। इसमें, आप अपनी कमजोरियों, कीड़े, तकनीकी ऋण और अधिक की गतिशीलता देख सकते हैं।
जटिलता परीक्षण
फ्रंटेंडर्स लिंटर का उपयोग
करते हैं क्योंकि वे सुंदर इंडेंटेशन चाहते हैं । जटिलता भी एक नरम-परीक्षण है जिसके साथ आप अपने कोड की गुणवत्ता की जांच करने का प्रयास कर सकते हैं।
तस्वीर में दिखाया गया है कि कैसे मैं उस जूनियर के विचार का पालन करने की कोशिश कर रहा हूं जिसने पुल अनुरोध किया था। ऐसे मामलों में, मैं सब कुछ ध्वस्त करने और एक सीधी सड़क बनाने का सुझाव देता हूं।जटिलता परीक्षण एक बहुत ही सरल सिद्धांत का पालन करते हैं: वे एल्गोरिथ्म के
चक्रवाती जटिलता की गणना करते हैं। उदाहरण के लिए, वे एक फ़ंक्शन पढ़ते हैं, इसमें 10 चर मिलते हैं। अगर 10 - शायद यह मुश्किल है। आइए जटिलता को निर्धारित करें। 1. प्रत्येक चक्र के लिए हम 3 अंक देंगे, एक चक्र में एक चक्र के लिए - 9, एक चक्र के प्रत्येक चक्र के लिए - 27। हम सब कुछ जोड़ते हैं और कहते हैं: साइक्लोमैटिक जटिलता 120, और एक व्यक्ति केवल समझ सकता है 6. इस मूल्यांकन का अर्थ है व्यक्तिपरक रूप से कहने के लिए कि आपको अपने स्रोत कोड को फिर से लिखने की जरूरत है, इसे टुकड़ों में तोड़ दें, नए कार्यों को उजागर करें और पसंद करें। और हाँ, सोनारक्यूब भी कर सकते हैं।
वैकल्पिक परीक्षण
मेरी दुनिया में, वैकल्पिक परीक्षण नरम परीक्षणों पर भी लागू होते हैं।
एकजुटता ऑनबोर्डिंग के लिए एक बहुत ही उपयोगी चीज है। और न केवल फ्रंट-एंड के लिए, हालांकि यह जावास्क्रिप्ट में लिखा गया है। यह आपको
काम के माहौल का
परीक्षण करने की अनुमति देता
है । पहले, विशाल निर्देशों की रचना करना आवश्यक था, प्रोग्रामिंग भाषा के संस्करणों, पुस्तकालयों, आवश्यक सॉफ्टवेयर की सूची को इंगित करने के लिए, बस शुरू करने के लिए, सब कुछ अद्यतित रखना आदि। अब हम यह कह सकते हैं: “यहाँ आपका कंप्यूटर है, यहाँ स्रोत कोड है। जब तक
एकजुटता नहीं होगी, तब तक मत आना। ” इसी समय, प्रवेश सीमा कम है। एकजुटता एक काम के माहौल के फिंगरप्रिंट बना सकती है और आपको न केवल स्थापित सॉफ़्टवेयर को मान्य करने के लिए बहुत सरल नियम जोड़ने की अनुमति देती है। और यह आपको तब प्रभावित करता है जब वे शब्दों के साथ आते हैं: "ओह, मुझे क्षमा करें, मेरे लिए कुछ काम नहीं है, क्या आप मदद कर सकते हैं?"
दूसरा उपयोग मामला (यह मुख्य है)
उत्पादन पर्यावरण को शब्दों के साथ
परीक्षण कर रहा है : "CI के लिए यूनिट परीक्षण निश्चित रूप से पारित हो गए, लेकिन CI और PROD के विन्यास में काफी भिन्नता है। तो कोई गारंटी नहीं है ... "। पुस्तकालय का लक्ष्य बहुत सरल है: निरंतर एकीकरण के पहले नियम को पूरा करने के लिए: "सभी के पास समान वातावरण होना चाहिए।" स्वच्छ, अलग-थलग ताकि कोई साइड इफेक्ट न हो, ठीक है, या कम से कम इतना है कि उनमें से कम हैं ... मैं किसे मूर्ख बनाने की कोशिश कर रहा हूं?
एपीआई कॉल
ऐसा होता है कि डेवलपर्स को कई टीमों में विभाजित किया जाता है - कुछ एक फ्रंटएंड लिखते हैं, अन्य एक बैकेंड लिखते हैं। एक काल्पनिक स्थिति जो एक वास्तविक टीम में नहीं हो सकती है: सब कुछ कल काम किया, और आज दो रिलीज के बाद - सामने और पीछे - सब कुछ टूट गया। किसे दोष देना है? मैं, शुरू में बैकेंड अनुभव वाले व्यक्ति के रूप में, हमेशा कहता हूं: फ्रंट-एंड।
यह सरल है, उन्होंने हमेशा की तरह गड़बड़ कर दिया। एक बिंदु पर, फ्रंट-एंड विक्रेता आते हैं और कहते हैं: "यहां हमने
संदर्भ द्वारा पोस्ट को पढ़ा, गाइड के माध्यम से जाना और
अपने REST एपीआई को कैसे बनाया जाए, यह सीखा । और आप विश्वास नहीं करेंगे कि यह बदल गया है ... " सामान्य तौर पर, यदि आपके बैकएंड स्वैगर, ओपनएपीआई या इसी तरह के अन्य समाधानों के साथ दोस्त नहीं हैं - यह ध्यान देने योग्य है।
प्रदर्शन जे.एस.
और अंत में, प्रदर्शन जेएस परीक्षण। ब्राउज़र निर्माताओं को छोड़कर
कोई भी जेएस प्रदर्शन का परीक्षण नहीं कर रहा है । एक नियम के रूप में, वे सभी
बेंचमार्क का उपयोग करते हैं। "ओह, और हमने 18 साल के लिए अपने एक्सप्लोरर को घर कर लिया है ताकि यह क्रोम की तुलना में एक बिलियन-प्रति-बिलियन टैबलेट तेजी से प्रदर्शित हो।" इस तरह की गोली की ज़रूरत किसे है?
यदि आप प्रदर्शन परीक्षण करना चाहते हैं, तो दूसरे रास्ते पर जाना बेहतर है: एंड-टू-एंड का परीक्षण करें और देखें कि यह कैसे काम करता है। उपयोगकर्ता एक धारणा बनाता है कि एप्लिकेशन समग्र रूप से कैसे काम करता है,
उपयोगकर्ता को यह ध्यान नहीं है कि ये बैकएंड की तरफ समस्या हैं।युद्ध की कहानी # 1
अब जीवन से एक उदाहरण। किसी तरह मालिक हमारे पास आते हैं और कहते हैं: “आपका मोर्चा बहुत खराब काम कर रहा है, यह मुश्किल से लोड हो रहा है। प्रदर्शन के साथ कुछ करने की जरूरत है, लोग शिकायत कर रहे हैं। ” हम सोचते हैं: अब हमारे पास ट्यूनिंग करने के लिए दो सप्ताह का समय है, लॉग्स लेने के लिए
आपने अपडेट क्यों किया , ट्री शेकिंग को चुनना, गतिशील लोडिंग के साथ सभी चीज़ों को काटना ... क्या होगा अगर यह बाहर नहीं जला है, तो हम इसे पूरी तरह से तोड़ देंगे या बस इसे खराब कर देंगे? एक वैकल्पिक समाधान बनाने की जरूरत है।
हम ब्राउज़र खोलते हैं, देखो: 7.5 एमबी, 2 सेकंड, सब कुछ ठीक है।
Nginx GZip रखो:
Nginx में संपीड़न अनुपात समायोजित करने की क्षमता है, आइए कोशिश करते हैं:
विकास - उत्पादकता का 25%। जल्दी बंद करो। कोने में छोटे डिजाइनर लोगो को देखें। यह बहुत सुंदर बना हुआ है, भले ही यह फैला हुआ है, लेकिन हमें इसकी आवश्यकता क्यों है?
यहाँ आपको एक चित्र के अनुकूलन के बाद क्या मिला है। आप स्वयं लोगो के वजन का मूल्यांकन कर सकते हैं। अंत में, हम ग्राहक के पास आते हैं और कहते हैं: “पहला डाउनलोड दूसरा महत्वपूर्ण नहीं है। और, मजबूर कैशिंग सक्षम करें:
... हर कोई खुश है, हर कोई खुश है! " उपयोगकर्ता के अलावा, बिल्कुल।
नतीजतन, हमने अधिक बार एक आकार ऑडिट आयोजित करने का फैसला किया।
गज़िप, फोंट, चित्र, शैलियाँ - वे जगहें जहाँ शायद ही कोई दिखता हो, लेकिन इसके कई फायदे हैं।
मैज और updtrJS
अगला चरण:
निर्भरता ऑडिटिंग ।
मैडेज एक ऐसी चीज है जो कोड का विश्लेषण करती है और कहती है: यहां एक वर्ग ऐसा है, जो इतने-और-तो-आदि से जुड़ा है। यदि सब कुछ एक घटक के माध्यम से जाता है और यह टूट जाता है, तो थोड़ा सुखद होगा। मैज एक महान दृश्य उपकरण है, लेकिन केवल मैनुअल अन्वेषण के लिए उपयुक्त है। इसके पास एक ऐसा विकल्प, परिपत्र है, जो
आपकी परियोजना में सभी
चक्रीय निर्भरता की खोज
करता है । यदि कोई हो, यह खराब है, यदि नहीं, तो वे अभी तक लिखे नहीं गए हैं।
विरासत ढांचे और पुस्तकालयों का दर्द
updtrJS के साथ लगभग हल हो
गया है ।
क्या आपके पास कोड की 70 हजार लाइनें हैं? क्या आप 13 वें रिएक्ट से 16 वें स्थान पर जाने की कोशिश कर रहे हैं?
अपडेटर आपको स्थानांतरित
करने में मदद नहीं करेगा , लेकिन यह आपको यह बताने में मदद करेगा कि पुस्तकालयों के कौन से संस्करण आप
गंभीर परिणामों के बिना स्थानांतरित कर सकते हैं। इसके अलावा, यह डेवलपर्स को प्रवृत्ति में रहने की अनुमति देता है, अप-टू-डेट निर्भरता रखने में मदद करता है। यदि आपके पास अच्छा परीक्षण कवरेज है, तो मैं सलाह देता हूं।
स्थैतिक प्रकार
जेएस स्टैटिक टाइपिंग का उपयोग करें , क्योंकि
जेएस डायनेमिक टाइपिंग एक विशेषता नहीं है, यह एक खाई है। प्रवाह, टाइपस्क्रिप्ट, reasonML यह सब है ...
कैओस परीक्षण
अराजकता परीक्षण का सार सरल है: ब्राउज़र को शुरू करें और जो कुछ भी पोक किया गया है, उसे पोक करना शुरू करें, वह सब कुछ दर्ज करें जो सभी क्षेत्रों में दर्ज किया गया है, और इसी तरह। जब तक वह टूट न जाए। Amazon, exceptions . , « , ». , . :
Gremlin.com Chaos Monkey .
React — 16- , componentDidCatch. , exception, . .
Naughty String , , . , « », internal server error, ?
War Story #2
– . . def generateRandomPostfix(String prefix) { return prefix + "-" + Math.abs(new Random().nextInt()).toString() } def "testCorrectRandomPostfix"(){ given: def prefix = "ASD" when: def result = generateRandomPostfix(prefix) then: result?.matches(/[a-zA-Z]++-[0-9]++/) }
. . , .
. ASD, , . . ( , groovy). Java integer 1 integer. integer integer — .
, . . ? «+» fromX. , - , XML .
.
.
TestCheck.JS — . , , . —
Flow-To-Gen : Flow , .
check( property( gen.int, gen.int, (a, b) => a + b >= a && a + b >= b ) )
{ result: false, failingSize: 2, numTests: 3, fail: [ 2, -1 ], shrunk: { totalNodesVisited: 2, depth: 1, result: false, smallest: [ 0, -1 ] } }
TestCheck « », . , . , , : 0 -1. 2 -1, , . !
. . , . , ? -? permission'? ? , , , , .
3rd party failures . „ “ — .
Production-
production 16- React :
ErrorCeption HoneyBadger (
Sentry ). ,
.Optimizely /-. , , , , , .
Out of the box
JS — . , JavaScript. —
validator.w3.org/checklink . , , , , .
, , .
Achecker.ca/checker .
Webpagetest.org — , .
Tools.pingdom.com — .
www.w3.org/WAI/ER/tools .
. . , Jenkins Multibranch Plugin, - -. -, (« , »), nightly-, - regress, full regress, smart regress ..
— , , , , . , , , .
, , . .