👲🏻 👨🏼‍🔬 🍅 मिथुन और स्टोरीबुक पर आधारित दृश्य परीक्षणों का विकास 🏇🏼 ⛷️ 👩🏻‍💻

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

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

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

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

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

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

उपकरण चयन

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

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

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

//.gemini.js module.exports = { rootUrl: 'http://my-app.ru', gridUrl: 'http://127.0.0.1:4444/wd/hub', browsers: { chrome: { windowSize: '1920x1080', screenshotsDir:'gemini/screens/1920x1080' desiredCapabilities: { browserName: 'chrome' } } }, system: { projectRoot: '', plugins: { 'html-reporter/gemini': { enabled: true, path: './report' }, 'gemini-optipng': true }, exclude: [ '**/report/*' ], diffColor: '#EC041E' } };

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

एक उदाहरण:

 gemini.suite('login-dialog', suite => { suite.setUrl('/') .setCaptureElements('.login__form') .capture('default'); .capture('focused', actions => actions.focus('.login__editor')); });

डेटा का परीक्षण करें

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

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

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

Redux स्टोर की वर्तमान स्थिति को क्रमबद्ध करने के लिए, स्नैपशॉट () विधि को विंडो ऑब्जेक्ट में जोड़ा गया है:

 export const snapshotStore = (store: Object, fileName: string): string => { let state = store.getState(); const file = new Blob( [ JSON.stringify(state, null, 2) ], { type: 'application/json' } ); let a = document.createElement('a'); a.href = URL.createObjectURL(file); a.download = `${fileName}.testdata.json`; a.click(); return `State downloaded to ${a.download}`; }; const store = createStore(reducer); if (process.env.NODE_ENV !== 'production') { window.snapshot = fileName => snapshotStore(store, fileName); };

इस विधि का उपयोग करते हुए, ब्राउज़र कंसोल की कमांड लाइन का उपयोग करके, आप Redux स्टोरेज की वर्तमान स्थिति को एक फाइल में सेव कर सकते हैं:

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

इसलिए, प्रत्येक दृश्य परीक्षण एक कहानी है, जिसके प्रतिपादन से पहले फ़ाइल में पहले से सहेजे गए रिड्यूक्स स्टोरेज की स्थिति बहाल हो जाती है। यह रिएक्टर-रिड्यूक्स लाइब्रेरी से प्रदाता घटक का उपयोग करके किया जाता है, जिस स्टोर की संपत्ति में पहले से बचाई गई फ़ाइल से पुनर्स्थापित की गई स्थिति को पारित किया जाता है:

 import preloadedState from './incoming-letter.testdata'; const store = createStore(rootReducer, preloadedState); storiesOf('regression/Cards', module) .add('IncomingLetter', () => { return ( <Provider store={store}> <MemoryRouter> <ContextContainer {...dummyProps}/> </MemoryRouter> </Provider> ); });

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

एक स्टोरीबुक के संदर्भ में, यह कुछ इस तरह दिखता है:

मिथुन + स्टोरीबुक

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

 const port = 6006; const cofiguration = { rootUrl:`localhost:${port}`, gridUrl: seleniumGridHubUrl, browsers: { 'chrome': { screenshotsDir:'gemini/screens', desiredCapabilities: chromeCapabilities } } }; const Gemini = require('gemini'); const HttpServer = require('http-server'); const runner = new Gemini(cofiguration); const server = HttpServer.createServer({ root: './storybook-static'}); runner.on(runner.events.START_RUNNER, () => { console.log(`storybook server is listening on ${port}...`); server.listen(port); }); runner.on(runner.events.END_RUNNER, () => { server.close(); console.log('storybook server is closed'); }); runner .readTests(path) .done(tests => runner.test(tests));

परीक्षण के लिए सर्वर के रूप में, हमने http-server का उपयोग किया, जो फ़ोल्डर की सामग्री को स्टेटिकली असेंबल स्टोरीबुक (स्टैटिक स्टोरीबुक बनाने के लिए, बिल्ड-स्टोरीबुक कमांड का उपयोग करता है) के साथ देता है।

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

 gemini.suite('VisualRegression', suite => suite.setUrl('http://localhost:6006/iframe.html?selectedKind=regression%2Fcards&selectedStory=IncomingLetter') .setCaptureElements('.some-component') .capture('IncomingLetter') );

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

 gemini.suite('VisualRegression', suite => suite.setUrl('/') .setCaptureElements('#storybook-preview-iframe') .capture('IncomingLetter', actions => openStory(actions, 'IncomingLetter')) .capture('ProjectDocument', actions => openStory(actions, 'ProjectDocumentAccess')) .capture('RelatedDocuments', actions => { openStory(actions, 'RelatedDocuments'); hover(actions, '.related-documents-tree-item__title', 4); }) );

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

 function openStory(actions, storyName) { const storyNameLowered = storyName.toLowerCase(); const clickTo = function(window) { Array.from(window.document.querySelectorAll('a')).filter( function(el) { return el.textContent.toLowerCase() === 'storyNameLowered'; })[0].click(); }; actions.executeJS(eval(`(${clickTo.toString().replace('storyNameLowered', storyNameLowered)})`)); } function dispatchEvents(actions, targets, index, events) { const dispatch = function(window) { const document = window.document.querySelector('#storybook-preview-iframe').contentWindow.document; const target = document.querySelectorAll('targets')[index || 0]; events.forEach(function(event) { const clickEvent = document.createEvent('MouseEvents'); clickEvent.initEvent(event, true, true); target.dispatchEvent(clickEvent); }); }; actions.executeJS(eval(`(${dispatch.toString() .replace('targets', targets) .replace('index', index) .replace('events', `["${events.join('","')}"]`)})` )); } function hover(actions, selectors, index) { dispatchEvents(actions, selectors, index, [ 'mouseenter', 'mouseover' ]); } module.exports = { openStory: openStory, hover: hover };

निष्पादन की पुनरावृत्ति

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

 const SuiteCollection = require('gemini/lib/suite-collection'); const Suite = require('gemini/lib/suite'); let retrySuiteCollection; let retryCount = 2; runner.on(runner.events.BEGIN, () => { retrySuiteCollection = new SuiteCollection(); }); runner.on(runner.events.TEST_RESULT, args => { const testId = `${args.state.name}/${args.suite.name}/${args.browserId}`; if (!args.equal) { if (retryCount > 0) console.log(chalk.yellow(`failed ${testId}`)); else console.log(chalk.red(`failed ${testId}`)); let suite = retrySuiteCollection.topLevelSuites().find(s => s.name === args.suite.name); if (!suite) { suite = new Suite(args.suite.name); suite.url = args.suite.url; suite.file = args.suite.file; suite.path = args.suite.path; suite.captureSelectors = [ ...args.suite.captureSelectors ]; suite.browsers = [ ...args.suite.browsers ]; suite.skipped = [ ...args.suite.skipped ]; suite.beforeActions = [ ...args.suite.beforeActions ]; retrySuiteCollection.add(suite); } if (!suite.states.find(s => s.name === args.state.name)) { suite.addState(args.state.clone()); } } else console.log(chalk.green(`passed ${testId}`)); });

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

टेस्ट रन पूरा होने पर, यदि नया सूट खाली नहीं है, तो इसे तब तक चलाएं, जब तक कि अधिकतम संख्या में दोहराव समाप्त न हो जाए:

 function onComplete(result) { if ((retryCount--) > 0 && result.failed > 0 && retrySuiteCollection.topLevelSuites().length > 0) { runner.test(retrySuiteCollection, {}).done(onComplete); } } runner.readTests(path).done(tests => runner.test(tests).done(onComplete));

सारांश

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

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

मिथुन और स्टोरीबुक पर आधारित दृश्य परीक्षणों का विकास

उपकरण चयन

डेटा का परीक्षण करें

मिथुन + स्टोरीबुक

निष्पादन की पुनरावृत्ति

सारांश

More articles: