📮 🕵️ 🏹 रिएक्ट घटकों का परीक्षण करने का एक सुविधाजनक तरीका 🤴🏽 🚔 ⏸️

मैंने जेस्ट के लिए एक कस्टम रिपोर्ट बिल्डर लिखा और इसे GitHub पर पोस्ट किया। मेरे बिल्डर को जेस्ट-स्नैपशॉट-बुक कहा जाता है, यह एक रिएक्ट एप्लिकेशन के घटकों के स्नैपशॉट की एक HTML पुस्तक बनाता है।

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

पेजिनेटर रिएक्टर घटक

एक उदाहरण के लिए, लेख में हम पेजिनेटर घटक ( पेजिनेटर ) का परीक्षण करेंगे। यह AWS ( GitHub ) में सर्वर रहित एप्लिकेशन बनाने के लिए हमारी परियोजना का हिस्सा है। इस तरह के एक घटक का कार्य एक मेज या कुछ और के पन्नों के माध्यम से नेविगेट करने के लिए बटन प्रदर्शित करना है।

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

पेजिनेटर घटक कोड

import React from 'react'; import classes from './Paginator.css'; import Button from '../../UI/Button/Button'; const Paginator = (props) => { const { tp, cp, pageClickHandler } = props; let paginator = null; if (tp !== undefined && tp > 0) { let buttons = []; buttons.push( <Button key={`pback`} disabled={cp === 1} clicked={(cp === 1 ? null : event => pageClickHandler(event, 'back'))}> ← </Button> ); const isDots = (i, tp, cp) => i > 1 && i < tp && (i > cp + 1 || i < cp - 1) && (cp > 4 || i > 5) && (cp < tp - 3 || i < tp - 4); let flag; for (let i = 1; i <= tp; i++) { const dots = isDots(i, tp, cp) && (isDots(i - 1, tp, cp) || isDots(i + 1, tp, cp)); if (flag && dots) { flag = false; buttons.push( <Button key={`p${i}`} className={classes.Dots} disabled={true}> ... </Button> ); } else if (!dots) { flag = true; buttons.push( <Button key={`p${i}`} disabled={i === cp} clicked={(i === cp ? null : event => pageClickHandler(event, i))}> {i} </Button> ); } } buttons.push( <Button key={`pforward`} disabled={cp === tp} clicked={(cp === tp ? null : event => pageClickHandler(event, 'forward'))}> → </Button> ); paginator = <div className={classes.Paginator}> {buttons} </div> } return paginator; } export default Paginator;

बटन घटक कोड

 import React from 'react'; import classes from './Button.css'; const button = (props) => ( <button disabled={props.disabled} className={classes.Button + (props.className ? ' ' + props.className : '')} onClick={props.clicked}> {props.children} </button> ); export default button;

जेस्ट

जावास्क्रिप्ट कोड परीक्षण के लिए जेस्ट एक प्रसिद्ध ओपनसोर्स लाइब्रेरी है। यह फेसबुक के लिए धन्यवाद बनाया और विकसित किया गया था। Node.js. में लिखा गया

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

Jestjs.io से एक छोटा सा उदाहरण।

मान लें कि हमारे पास एक Node.js मॉड्यूल है, जो एक फ़ंक्शन है जो दो नंबर ( sum.js फ़ाइल) जोड़ता है:

 function sum(a, b) { return a + b; } module.exports = sum;

यदि हमारे मॉड्यूल को किसी फ़ाइल में सहेजा जाता है, तो इसे जांचने के लिए, हमें sum.test.js फ़ाइल बनानी होगी जिसमें परीक्षण के लिए इस तरह का कोड लिखना है:

 const sum = require('./sum'); test('adds 1 + 2 to equal 3', () => { expect(sum(1, 2)).toBe(3); });

इस उदाहरण में, परीक्षण फ़ंक्शन का उपयोग करते हुए, हमने '1 + 2 को बराबर 3' कहते हुए एक परीक्षण बनाया। परीक्षण फ़ंक्शन के लिए दूसरा पैरामीटर, हम एक फ़ंक्शन पास करते हैं जो वास्तव में परीक्षण करता है।

परीक्षण में तथ्य यह है कि हम अपने योग फ़ंक्शन को इनपुट मापदंडों 1 और 2 के साथ निष्पादित करते हैं, परिणाम जेस्ट की अपेक्षा () फ़ंक्शन के लिए पास करते हैं। फिर, जेस्ट टू () फ़ंक्शन का उपयोग करते हुए, संचारित परिणाम की अपेक्षा ( 3 ) के साथ तुलना की जाती है। टोबी () फ़ंक्शन जेस्ट (मैचर्स) परीक्षण कार्यों की श्रेणी से संबंधित है।

परीक्षण के लिए, बस प्रोजेक्ट फ़ोल्डर पर जाएं और कमांड लाइन पर जेस्ट को कॉल करें। जेस्ट एक्सटेंशन .test.js के साथ फाइल ढूंढेगा और परीक्षण चलाएगा। यहाँ परिणाम वह उत्पादन होगा:

 PASS ./sum.test.js ✓ adds 1 + 2 to equal 3 (5ms)

घटकों के एंजाइम और स्नैपशॉट परीक्षण

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

इस मामले में स्नैपशॉट डेटा के एक पाठ प्रतिनिधित्व से अधिक कुछ नहीं है। उदाहरण के लिए, किसी वस्तु का एक स्नैपशॉट कुछ इस तरह दिखेगा (यहाँ सरणी कुंजी परीक्षण का नाम है):

 exports[`some test name`] = ` Object { "Hello": "world" } `;

यह जेस्ट टेस्ट फ़ंक्शन जैसा दिखता है, जो छवि तुलना (वैकल्पिक पैरामीटर) करता है:

 expect(value).toMatchSnapshot(propertyMatchers, snapshotName)

मान किसी भी क्रमबद्ध डेटा संरचना हो सकता है। पहली बार, toMatchSnapshot () फ़ंक्शन केवल स्नैपशॉट को डिस्क पर लिखता है, बाद के समय में, यह पहले से ही तुलना करेगा।

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

एंजाइम एक पुस्तकालय है जो सुविधाजनक घटक रेंडरिंग फ़ंक्शन प्रदान करके प्रतिक्रिया अनुप्रयोगों के परीक्षण को बहुत सरल करता है। एंजाइम Airbnb में विकसित किया गया है।

एंजाइम आपको कोड में घटकों को प्रस्तुत करने की अनुमति देता है। इसके लिए कई सुविधाजनक कार्य हैं जो अलग-अलग प्रतिपादन विकल्प प्रदान करते हैं:

पूर्ण प्रतिपादन (ब्राउज़र में, पूर्ण डोम प्रतिपादन);
सरलीकृत प्रतिपादन (उथले प्रतिपादन);
स्थिर प्रतिपादन

हम स्नैपशॉट परीक्षण के लिए, रेंडरिंग विकल्पों में तल्लीन नहीं करेंगे, स्थैतिक प्रतिपादन पर्याप्त है, जो आपको घटक और उसके बाल घटकों के स्थिर HTML-कोड प्राप्त करने की अनुमति देता है:

 const wrapper = render(<Foo title="unique" />);

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

 ... const wrapper = render(<Paginator tp={tp} cp={cp} />); it(`Total = ${tp}, Current = ${cp}`, () => { expect(wrapper).toMatchSnapshot(); }); ...

हर बार परीक्षण चलाया जाता है, toMatchSnapshot () दो स्नैपशॉट की तुलना करता है: अपेक्षित (जो पहले डिस्क पर लिखा गया था) और वर्तमान (जो वर्तमान परीक्षण के दौरान प्राप्त किया गया था)।

यदि चित्र समान हैं, तो परीक्षण पास माना जाता है। यदि चित्रों में अंतर होता है, तो परीक्षण को पास नहीं माना जाता है, और उपयोगकर्ता को अंतर के रूप में दो चित्रों के बीच का अंतर दिखाया जाता है (जैसा कि संस्करण नियंत्रण प्रणालियों में)।

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

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

मैं एक पेजिनेटर (फ़ाइल Paginator.test.js ) के परीक्षण के लिए एक पूर्ण उदाहरण दूंगा ।

अधिक सुविधाजनक पेजिनेटर परीक्षण के लिए, मैंने एक स्नैपशॉट (tp, cp) फ़ंक्शन बनाया जो दो मापदंडों को लेगा: पृष्ठों की कुल संख्या और वर्तमान पृष्ठ। यह फ़ंक्शन दिए गए मापदंडों के साथ एक परीक्षण करेगा। सभी अवशेषों को स्नैपशॉट () फ़ंक्शन को विभिन्न मापदंडों (यहां तक कि एक लूप में) और परीक्षण, परीक्षण ... के साथ कॉल करना है

 import React from 'react'; import { configure, render } from 'enzyme'; import Adapter from 'enzyme-adapter-react-16'; import Paginator from './Paginator'; configure({ adapter: new Adapter() }); describe('Paginator', () => { const snapshoot = (tp, cp) => { const wrapper = render(<Paginator tp={tp} cp={cp} />); it(`Total = ${tp}, Current = ${cp}`, () => { expect(wrapper).toMatchSnapshot(); }); } snapshoot(0, 0); snapshoot(1, -1); snapshoot(1, 1); snapshoot(2, 2); snapshoot(3, 1); for (let cp = 1; cp <= 10; cp++) { snapshoot(10, cp); } });

आपको एक अतिरिक्त रिपोर्ट बिल्डर की आवश्यकता क्यों थी

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

लेकिन क्या होगा अगर कुछ घटक रेंडर करते समय बहुत सारे HTML कोड का उत्पादन करता है? यहाँ एक 3-बटन पेजिनेटर घटक है। इस तरह के एक घटक का एक स्नैपशॉट इस तरह दिखेगा:

 exports[`Paginator Total = 1, Current = -1 1`] = ` <div class="Paginator" > <button class="Button" > ← </button> <button class="Button" > 1 </button> <button class="Button" > → </button> </div> `;

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

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

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

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

जेस्ट रिपोर्ट बिल्डर्स

जेस्ट के रचनाकारों ने अतिरिक्त रिपोर्ट बिल्डरों को लिखने का अवसर प्रदान किया है। यह निम्नानुसार किया जाता है। आपको Node.JS पर एक मॉड्यूल लिखने की आवश्यकता है जिसमें इन विधियों में से एक या अधिक होना चाहिए: onRunStart , onTestStart , onTestResult , onRunComplete , जो परीक्षण प्रगति की विभिन्न घटनाओं के अनुरूप हैं।

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

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

जेस्ट-स्नैपशॉट्स-बुक कैसे काम करती है

मैं विशेष रूप से लेख में मॉड्यूल कोड नहीं डालूंगा, क्योंकि मैं इसे और सुधारूंगा। यह मेरे GitHub पर पाया जा सकता है, यह प्रोजेक्ट पेज पर src / index.js फ़ाइल है ।

मेरी रिपोर्ट बिल्डर परीक्षण पूरा होने पर कहा जाता है। मैंने कोड onRunComplete (संदर्भ, परिणाम) विधि में डाला। यह निम्नानुसार काम करता है।

Results.testResults प्रॉपर्टी में, Jest इस फ़ंक्शन के लिए परीक्षण परिणामों की एक सरणी से गुजरता है। प्रत्येक परीक्षा परिणाम में परीक्षण फ़ाइल का पथ और परिणामों के साथ संदेशों की एक सरणी शामिल होती है। मेरी रिपोर्ट बिल्डर संगत स्नैपशॉट फ़ाइल के साथ प्रत्येक परीक्षण फ़ाइल के लिए खोज करता है। यदि स्नैपशॉट फ़ाइल का पता लगाया जाता है, तो रिपोर्ट बिल्डर स्नैपशॉट पुस्तक में एक HTML पृष्ठ बनाता है और इसे प्रोजेक्ट रूट फ़ोल्डर में स्नैपशॉट-पुस्तक फ़ोल्डर में लिखता है।

HTML पेज जेनरेट करने के लिए, ग्रैबसीएसएस रिकर्सिव फंक्शन (मॉड्यूलनाम, सीएसएस = [], लेवल = 0) का उपयोग करके रिपोर्ट बिल्डर, सभी शैलियों को इकट्ठा करता है, परीक्षण के तहत घटक से शुरू होता है और इसके आयात वाले सभी घटकों के पेड़ को नीचे गिराता है । इस प्रकार, फ़ंक्शन उन सभी शैलियों को इकट्ठा करता है जो घटक को सही ढंग से प्रदर्शित करने के लिए आवश्यक हैं। एकत्रित शैलियों को स्नैपशॉट पुस्तक के HTML पृष्ठ में जोड़ा जाता है।

मैं अपनी परियोजनाओं में सीएसएस मॉड्यूल का उपयोग करता हूं, इसलिए मुझे यकीन नहीं है कि अगर सीएसएस मॉड्यूल का उपयोग नहीं किया जाता है तो यह काम करेगा।

यदि परीक्षण पास हो जाता है, तो बिल्डर दो प्रदर्शन विकल्पों में छवि के साथ HTML पृष्ठ में एक iFrame सम्मिलित करता है: स्रोत कोड (छवि जैसा है) और प्रतिपादन के बाद घटक। IFrame में डिस्प्ले ऑप्शन माउस को क्लिक करके बदला जाता है।

यदि परीक्षण पारित नहीं किया गया था, तो सब कुछ अधिक जटिल है। जेस्ट इस मामले में केवल वह संदेश प्रदान करता है जो वह कंसोल में प्रदर्शित करता है (ऊपर स्क्रीनशॉट देखें)।

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

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

रिपोर्ट बिल्डर का आउटपुट कैसा दिखता है यदि आप इसके लिए वर्बोज़ = सही विकल्प सेट करते हैं।

उपयोगी लिंक

पुनश्च

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

रिएक्ट घटकों का परीक्षण करने का एक सुविधाजनक तरीका