🤷🏻 🤸🏿 📔 दृश्य प्रतिगमन परीक्षण। रिबूट 🤳🏼 👨🏼‍🔬 ♣️

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

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

प्रदर्शन अनुकूलन

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

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

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

परीक्षणों में स्क्रीनशॉट के क्षेत्र को सीमित करने में असमर्थता संदर्भ छवियों में दृश्य जानकारी के दोहराव का कारण बनी। जबकि कई परीक्षण नहीं थे, यह समस्या महत्वपूर्ण नहीं थी। हां, और UI बहुत बार नहीं बदला। लेकिन यह हमेशा के लिए नहीं जा सका - क्षितिज पर एक नया स्वरूप।

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

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

// visual-regression.stories.js import React from 'react'; import StoryProvider from './story-provider'; const stories = storiesOf('visual-regression', module); [ { name: 'Contract', loadData: import('./snapshots/contract.testdata') }, { name: 'ExecutionTask', loadData: import('./snapshots/execution-task.testdata') }, { name: 'ExecutionAssignment', loadData: import('./snapshots/execution-assignment.testdata') }, { name: 'DocumentTemplate', loadData: import('./snapshots/document-template.testdata') }, { name: 'Explorer', loadData: import('./snapshots/explorer.testdata') }, { name: 'Inbox', loadData: import('./snapshots/inbox.testdata') }, ] .map(story => { stories .add(story.name, () => <StoryProvider loadSnapshot={story.loadData} />) .add(`${story.name}Dark`, () => <StoryProvider loadSnapshot={story.loadData} theme='night' />); });

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

डिफ़ॉल्ट विषय कहानी

डार्क थीम कहानी

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

कहानी-provider.js

 // story-provider.js const propsStub = { // -,      . . . }; type Props = { loadSnapshot: () => Object, theme: ?string }; const StoryProvider = (props: Props) => { const [ snapshotState, setsnapshotState ] = React.useState(null); React.useEffect(() => { //    (async() => setsnapshotState((await props.loadSnapshot).default))(); }); if (!snapshotState) //     ,     return <div className={'loading-stub'}>Loading...</div>; //    snapshotState.metadata = require('./snapshots/metadata'); //  redux-   const store = createMockStore(snapshotState); //   applyTheme(props.theme); return ( <Provider store={store}> <MemoryRouter> <App {...propsStub} /> </MemoryRouter> </Provider> ); }; export default StoryProvider;

इसके अतिरिक्त, बंडल के आकार को कम करने के लिए, बंडल में स्रोत मानचित्रों को जोड़ना अक्षम करें। लेकिन कहानी को डिबग करने की क्षमता नहीं खोने के लिए (आप कभी नहीं जानते कि क्या है), हम इस शर्त के तहत ऐसा करते हैं:

.storybook / webpack.config.js

 // .storybook/webpack.config.js ... module.exports = { ... devtool: process.env.NODE_ENV === 'vr-test' ? '(none)' : 'eval-source-map' };

package.json

 // package.json { ... "scripts": { ... "storybook": "start-storybook", "build-storybook": "cross-env NODE_ENV=vr-test build-storybook -o ./storybook-static", ... },

एनपीएम रन बिल्ड-स्टोरीबुक स्क्रिप्ट स्टोरीमैप-स्टेटिक फ़ोल्डर में सोर्समैप के बिना एक स्थिर स्टोरीबुक संकलित करता है। परीक्षण करते समय इसका उपयोग किया जाता है। और npm रन स्टोरीबुक स्क्रिप्ट का उपयोग परीक्षण कहानियों को विकसित करने और डिबग करने के लिए किया जाता है।

दृश्य जानकारी के दोहराव का उन्मूलन

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

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

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

हमारे मामले के लिए, प्रत्येक व्यक्तिगत कहानी के लिए परीक्षण कुछ इस तरह दिखाई देगा:

 //    describe('Visual regression', function() { it('Contract card should equal to etalon', function() { return this.browser //  story   .url('http://localhost:8080/iframe.html?selectedKind=visual-regression&selectedStory=ContractDark') // ,      story .waitForVisible('.loading-stub', true) //          .assertView('layout', '.form'); }) });

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

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

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

बनाने के परीक्षण-suite.js

 const themes = [ 'default', 'dark' ]; const rootClassName = '.explorer'; const loadingStubClassName = '.loading-stub'; const timeout = 2000; function createTestSuite(testSuite) { const { name, storyName, browsers, testCases, selector } = testSuite; //  ,       browsers && hermione.only.in(browsers); //      themes.forEach(theme => { describe(`${name}_${theme}`, () => it('should equal to etalon', function() { let browser = this.browser //   story .url(`${storybookUrl}/iframe.html?selectedKind=visual-regression&selectedStory=${storyName}-${theme}`) //     .waitForVisible(loadingStubClassName, timeout, true) .waitForVisible(rootClassName); //    (  ) if (testCases && testCases.length > 0) { testCases.forEach(testCase => { if (testCase.before) browser = testCase.before(browser); browser = browser.assertView(`${name}__${testCase.name}_${theme}`, testCase.selector || selector || rootClassName, testCase.options); }); return browser; } //    ,    return browser.assertView(`${name}_${theme}`, selector || rootClassName); })); }); }

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

एक्सप्लोरर-suite.js

 // explorer-suite.js //         module.exports = { //  story,    storyName: 'explorer', //    name: 'explorer', //  ,       browsers: [ 'chrome-1920x1080', 'ie-1920x1080' ], //   testCases: [ { //    name: 'layout' }, { //    name: 'notification-area', selector: '.notification-area__popup', before: b => b .click('.notification-area__popup-button') .waitForVisible('.notification-area__popup') .execute(function() { //       document.querySelectorAll('.expandable-item__content')[2].click(); }) }, //... ] };

tests.js

 // tests.js [ require('./suites/explorer-suite'), //... ] .forEach(suite => createTestSuite(suite));

कवरेज का निर्धारण

तो, हमने गति और अतिरेक का पता लगाया, यह हमारे परीक्षण की प्रभावशीलता का पता लगाने के लिए बना हुआ है, अर्थात, परीक्षण के साथ कोड की कवरेज की डिग्री निर्धारित करें (यहां कोड से मेरा मतलब सीएसएस शैली पत्रक) है।

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

Chrome DevTools में कवरेज का मूल्यांकन करने के लिए, इस नाम के लिए बहुत उपयुक्त कवरेज के साथ एक उपकरण है:

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

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

मैन्युअल मोड में परीक्षण चलाने के बाद, हमें एक कवरेज रिपोर्ट मिलती है, जो कि एक json फाइल है। प्रत्येक css, js, ts, आदि के लिए रिपोर्ट में। फ़ाइल इसके पाठ (एक पंक्ति में) और इस पाठ में प्रयुक्त कोड के अंतराल (इस पंक्ति के चरित्र सूचकांकों के रूप में) को इंगित करती है। नीचे रिपोर्ट का एक टुकड़ा है:

coverage.json

 [ { "url": "http://localhost:6006/theme-default.css", "ranges": [ { "start": 0, "end": 8127 } ], "text": "... --theme_primary-accent: #5b9bd5;\r\n --theme_primary-light: #ffffff;\r\n --theme_primary: #f4f4f4;\r\n ..." }, { "url": "http://localhost:6006/main.css", "ranges": [ { "start": 0, "end": 610 }, { "start": 728, "end": 754 } ] "text": "... \r\n line-height:1;\r\n}\r\n\r\nol, ul{\r\n list-style:none;\r\n}\r\n\r\nblockquote, q..." ]

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

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

coverage.js

 const modules = require('./coverage.json').filter(e => e.url.endsWith('.css')); function processRange(module, rangeStart, rangeEnd, isUsed) { const rules = module.text.slice(rangeStart, rangeEnd); if (rules) { const regex = /^\.([^\d{:,)_ ]+-?)+/gm; const classNames = rules.match(regex); classNames && classNames.forEach(name => selectors[name] = selectors[name] || isUsed); } } let previousEnd, selectors = {}; modules.forEach(module => { previousEnd = 0; for (const range of module.ranges) { processRange(module, previousEnd, range.start, false); processRange(module, range.start, range.end, true); previousEnd = range.end; } processRange(module, previousEnd, module.length, false); }); console.log('className;isUsed'); Object.keys(selectors).sort().forEach(s => { console.log(`${s};${selectors[s]}`); });

हम Chrome DevTools से निर्यात की गई कवरेज.json फ़ाइल को पहली बार डालकर स्क्रिप्ट निष्पादित करते हैं और निकास को .csv फ़ाइल में लिखते हैं:

नोड कवरेज। js> server.csv

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

इसके बजाय एक फिर से शुरू

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

एक नए इंजन में संक्रमण ने हमें स्क्रीनशॉट में दृश्य जानकारी के दोहराव को खत्म करने की अनुमति दी, जिसने मौजूदा परीक्षणों के समर्थन को बहुत सरल बना दिया।

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

दृश्य प्रतिगमन परीक्षण। रिबूट

प्रदर्शन अनुकूलन

दृश्य जानकारी के दोहराव का उन्मूलन

कवरेज का निर्धारण

इसके बजाय एक फिर से शुरू

More articles: