🛅 🖕🏿 🤦🏾 (इन) परिमित युद्ध 🅱️ 🐏 ♒️

युद्ध को प्रभावित करना

हमें एक समस्या है। परीक्षण के साथ समस्या। रिएक्ट घटकों के परीक्षण के साथ समस्या, और यह काफी मौलिक है। यह unit testing और integration testing बीच अंतर के बारे में है। यह उस अंतर के बारे में है जिसे हम इकाई परीक्षण कहते हैं और जिसे हम एकीकरण परीक्षण, आकार और कार्यक्षेत्र कहते हैं।

यह खुद के परीक्षण के बारे में नहीं है, लेकिन घटक वास्तुकला के बारे में है। परीक्षण घटकों , स्टैंडअलोन पुस्तकालयों और अंतिम अनुप्रयोगों के बीच अंतर के बारे में।

हर कोई सरल घटकों का परीक्षण करना जानता है (वे सरल हैं), शायद जानते हैं कि आवेदन (ई 2 ई) का परीक्षण कैसे करें। परिमित और अनंत चीजों का परीक्षण कैसे करें ...

समस्या को परिभाषित करें

प्रतिक्रिया घटक का परीक्षण करने के लिए 2 अलग-अलग तरीके हैं - shallow और बाकी सब, जिसमें mount , react-testing-library , webdriver और इतने पर शामिल हैं। केवल shallow विशेष है - बाकी एक ही तरीके से व्यवहार करते हैं।

और यह अंतर आकार के बारे में है, और गुंजाइश - WHAT के बारे में परीक्षण किया जाएगा, और आंशिक रूप से कैसे ।

संक्षेप में - shallow केवल React.createElement को कॉल रिकॉर्ड करेगा, लेकिन DOM तत्वों को रेंडर करने सहित कोई भी साइड इफेक्ट नहीं चल रहा है - यह React.createElement का एक पक्ष (बीजीय) प्रभाव है।

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

और समस्या निम्नलिखित है: you can NOT run each and every side effect ।

क्यों नहीं?

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

लेकिन यह एक समस्या नहीं है ... dumb components । वे गूंगे हैं, केवल प्रस्तुति परत शामिल है, लेकिन "साइड इफेक्ट्स" नहीं।
लेकिन यह Containers लिए एक समस्या है। जब तक वे गूंगे नहीं होते हैं, तब तक वे जो कुछ भी चाहते हैं, और पूरी तरह से साइड इफेक्ट के बारे में बताते हैं। वे समस्या हैं!

शायद, अगर हम "सही घटक" के नियमों को परिभाषित करते हैं तो हम आसानी से परीक्षण कर सकते हैं - यह हमारा मार्गदर्शन करेगा, और हमारी मदद करेगा।

TRDL: परिमित घटक

स्मार्ट और डंब घटक

दान Abramov के अनुसार अनुच्छेद प्रस्तुति घटक हैं:

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

उत्पत्ति के अनुसार: आदर्श अनुप्रयोग में ...
कंटेनर ट्री हैं। घटक ट्री लीफ्स हैं।

अंधेरे कमरे में काली बिल्ली का पता लगाएं

यहाँ गुप्त चटनी, एक बदलाव जो हमें इस परिभाषा में संशोधन करना है, " अंदर मौजूद है, दोनों में प्रस्तुतिकरण और कंटेनर घटक ** " , मुझे मूल लेख का हवाला देते हैं:

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

ठीक है, लेकिन नियम के बारे में क्या है, जो प्रस्तुति घटक इकाई को परीक्षण योग्य बनाता है - "बाकी ऐप पर कोई निर्भरता नहीं है" ?

दुर्भाग्य से, प्रस्तुति के घटकों में कंटेनरों को शामिल करके आप दूसरे को अनंत बना रहे हैं, और बाकी ऐप पर निर्भरता को इंजेक्ट कर रहे हैं।

संभवतः यह कुछ ऐसा नहीं है जिसे आप करने का इरादा कर रहे थे। इसलिए, मेरे पास कोई अन्य विकल्प नहीं है, लेकिन गूंगा घटक को परिमित बनाने के लिए:

प्रस्तुति घटक केवल अन्य प्रस्तुति घटकों में शामिल होना चाहिए

और एकमात्र सवाल, आपको पूछना चाहिए (अपने वर्तमान कोड आधार को देखते हुए): कैसे? : टेबलफ्लिप:!

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

समाधान 1 - DI

समाधान 1 सरल है - डंब घटक में नेस्टेड कंटेनर नहीं होते हैं - इसमें slots होते slots । बस "सामग्री" (बच्चों) को, सहारा के रूप में स्वीकार करें, और इससे समस्या हल होगी:

आप "अपने ऐप के बाकी हिस्सों" के बिना गूंगे घटक का परीक्षण करने में सक्षम हैं
आप धुएं / एकीकरण / e2e परीक्षण के साथ एकीकरण का परीक्षण करने में सक्षम हैं, परीक्षण नहीं।

 // Test me with mount, with "slots emty". const PageChrome = ({children, aside}) => ( <section> <aside>{aside}</aside> {children} </section> ); // test me with shallow, or real integration test const PageChromeContainer = () => ( <PageChrome aside={<ASideContainer />}> <Page /> </PageChrome> );

स्वयं दान द्वारा स्वीकृत:
{% ट्विटर 1021850499618955272%}

DI (डिपेंडेसी इंजेक्शन और डिपेंडेंसी इनवर्सन दोनों), शायद, यहां सबसे पुन: प्रयोज्य तकनीक है, जो आपके जीवन को बहुत आसान बनाने में सक्षम है।

यहाँ बिंदु - गूंगे घटक गूंगे हैं!

समाधान 2 - सीमाएँ

यह एक काफी घोषणात्मक समाधान है, और Solution 1 विस्तार कर सकता है - बस सभी विस्तार बिंदुओं की घोषणा करें । बस उनके साथ लपेटो ... Boundary

 const Boundary = ({children}) => ( process.env.NODE_ENV === 'test' ? null : children // or `jest.mock` ); const PageChrome = () => ( <section> <aside><Boundary><ASideContainer /></Boundary></aside> <Boundary><Page /></Boundary> </section> );

तब - आप कंपोनेंट स्कोप को कम करने के लिए, शून्य, Boundary को अक्षम करने में सक्षम हैं, और इसे परिमित बनाते हैं।

यहाँ बिंदु - डम्ब घटक स्तर पर सीमा है। गूंगा घटक यह नियंत्रित कर रहा है कि यह कितना गूंगा है।

समाधान 3 - टीयर

समाधान 2 के समान ही है, लेकिन अधिक स्मार्ट बाउंड्री के साथ, परत या टीयर , या जो कुछ भी आप कहते हैं, उसका मज़ाक बनाने में सक्षम हैं:

 const checkTier = tier => tier === currentTier; const withTier = tier => WrapperComponent => (props) => ( (process.env.NODE_ENV !== 'test' || checkTier(tier)) && <WrapperComponent{...props} /> ); const PageChrome = () => ( <section> <aside><ASideContainer /></aside> <Page /> </section> ); const ASideContainer = withTier('UI')(...) const Page = withTier('Page')(...) const PageChromeContainer = withTier('UI')(PageChrome);

भले ही यह लगभग सीमा के उदाहरण के समान है - डंब घटक डंब है, और कंटेनर अन्य कंटेनरों की दृश्यता को नियंत्रित करते हैं।

समाधान 4 - अलग चिंताएं

एक और समाधान सिर्फ चिंताएं अलग करना है! मेरा मतलब है - आपने पहले से ही यह किया है, और शायद इसका उपयोग करने का समय है।

Redux या GQL connect आईएनजी घटक connect करके आप प्रसिद्ध कंटेनरों का उत्पादन कर रहे हैं। मेरा मतलब है - प्रसिद्ध नामों के साथ - Container(WrapperComponent) । आप उनके नाम से उनका मजाक उड़ा सकते हैं

 const PageChrome = () => ( <section> <aside><ASideContainer /></aside> <Page /> </section> ); // remove all components matching react-redux pattern reactRemock.mock(/Connect\(\w\)/) // all any other container reactRemock.mock(/Container/)

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

 import {createElement, remock} from 'react-remock'; // initially "open" const ContainerCondition = React.createContext(true); reactRemock.mock(/Connect\(\w\)/, (type, props, children) => ( <ContainerCondition.Consumer> { opened => ( opened ? ( // "close" and render real component <ContainerCondition.Provider value={false}> {createElement(type, props, ...children)} <ContainerCondition.Provider> ) // it's "closed" : null )} </ContainerCondition.Consumer> )

यहां इंगित करें: न तो कोई तर्क अंदर है और न ही प्रस्तुति, कंटेनर नहीं - सभी तर्क बाहर है।

बोनस सॉल्यूशन - अलग चिंताएं

आप defaultProps का उपयोग करके तंग युग्मन रख सकते हैं, और इन प्रॉप्स को परीक्षणों में defaultProps कर सकते हैं ...

 const PageChrome = ({Content = Page, Aside = ASideContainer}) => ( <section> <aside><Aside/></aside> <Content/> </section> );

तो?

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

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

तुम्हें पता है, जैसा कि दान ने अपने दूसरे लेख में लिखा है:

उदाहरण के लिए, यदि एक बटन 5 अलग-अलग राज्यों (सामान्य, सक्रिय, होवर, खतरे, अक्षम) में से एक में हो सकता है, तो बटन को अपडेट करने वाला कोड 5 × 4 = 20 संभावित संक्रमणों के लिए सही होना चाहिए - या उनमें से कुछ को मना करना चाहिए। हम संभावित राज्यों के दहनशील विस्फोट को कैसे रोक सकते हैं और दृश्य उत्पादन को अनुमानित कर सकते हैं?

जबकि यहाँ सही समाधान राज्य मशीनें हैं, जो एक परमाणु या अणु को चेरी-पिक करने में सक्षम हैं और इसके साथ खेलते हैं - आधार की आवश्यकता है।

इस लेख के मुख्य बिंदु

प्रेजेंटेशनल कंपोनेंट्स में केवल अन्य प्रेजेंटेशनल कंपोनेंट्स होने चाहिए।
कंटेनर ट्री हैं। घटक ट्री लीफ्स हैं।
आपको हमेशा प्रेजेंटेशनल वाले कंटेनरों में नहीं होना चाहिए , लेकिन उन्हें केवल परीक्षणों में शामिल नहीं करना चाहिए ।

आप मध्यम लेख को पढ़कर समस्या में गहराई से डुबकी लगा सकते हैं, लेकिन यहां हम सभी चीनी को छोड़ देते हैं।

PS: यह ru-habr लेख habr संस्करण का अनुवाद है।

(इन) परिमित युद्ध