टेस्ट सूट का आयोजन

जैसे-जैसे परियोजनाएं बढ़ती हैं, अनिवार्य रूप से अधिक से अधिक एकीकरण परीक्षण जोड़े जाते हैं। इससे निर्माण समय बढ़ता है और उत्पादकता धीमी हो जाती है।

इसे रोकने के लिए, आपको समानांतर में अपने परीक्षण चलाने चाहिए। WebdriverIO पहले से ही एक सत्र के भीतर समानांतर में प्रत्येक कल्पना (या ककड़ी में फीचर फ़ाइल) का परीक्षण करता है। सामान्य तौर पर, प्रति विशिष्ट फ़ाइल केवल एक विशेषता का परीक्षण करने का प्रयास करें। एक फ़ाइल में बहुत अधिक या बहुत कम परीक्षण न करने का प्रयास करें। (हालांकि, यहां कोई सुनहरा नियम नहीं है।)

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

मान लीजिए कि आपके पास 3 अलग-अलग क्षमताएं हैं (क्रोम, फ़ायरफ़ॉक्स और सफारी) और आपने maxInstances से 1सेट किया है। WDIO टेस्ट रनर 3 प्रोसेस को स्पॉन करेगा। इसलिए, यदि आपके पास 10 विशिष्ट फ़ाइलें हैं और आप maxInstances से 10, सेट करते हैं, तो सभी विशिष्ट फ़ाइलों का एक साथ परीक्षण किया जाएगा, और 30 प्रक्रियाओं को उत्पन्न किया जाएगा।

आप सभी ब्राउज़रों के लिए विशेषता सेट करने के लिए वैश्विक रूप से maxInstances प्रॉपर्टी को परिभाषित कर सकते हैं।

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

// wdio.conf.js
निर्यात कॉन्स्ट कॉन्फ़िगरेशन = {
    // ...
    // set maxInstance for all browser
    maxInstances: 10,
    // ...
    capabilities: [{
        browserName: 'firefox'
    }, {
        // maxInstances can get overwritten per capability. So if you have an in-house WebDriver
        // grid with only 5 firefox instance available you can make sure that not more than
        // 5 instance gets started at a time.
        browserName: 'chrome'
    }],
    // ...
}

मुख्य कॉन्फ़िग फ़ाइल से इनहेरिट करें

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

Similar to the page object concept, the first thing you’ll need is a main config file. इसमें आपके द्वारा परिवेशों में साझा किए गए सभी कॉन्फ़िगरेशन शामिल हैं।

फिर प्रत्येक वातावरण के लिए एक और कॉन्फ़िगरेशन फ़ाइल बनाएं, और मुख्य कॉन्फ़िगरेशन को पर्यावरण-विशिष्ट के साथ पूरक करें:

// wdio.dev.config.js
import { deepmerge } from 'deepmerge-ts'
import wdioConf from './wdio.conf.js'

// have main config file as default but overwrite environment specific information
export const config = deepmerge(wdioConf.config, {
    capabilities: [
        // more caps defined here
        // ...
    ],

    // run tests on sauce instead locally
    user: process.env.SAUCE_USERNAME,
    key: process.env.SAUCE_ACCESS_KEY,
    services: ['sauce']
}, { clone: false })

// add an additional reporter
config.reporters.push('allure')

सुइट्स में ग्रुपिंग टेस्ट स्पेक्स

आप परीक्षण विनिर्देशों को सुइट में समूहीकृत कर सकते हैं और उन सभी के बजाय एकल विशिष्ट सुइट चला सकते हैं।

सबसे पहले, अपने सुइट्स को अपने WDIO कॉन्फ़िगरेशन में परिभाषित करें:

// wdio.conf.js
निर्यात कॉन्स्ट कॉन्फ़िगरेशन = {
    // परिभाषित सभी परीक्षण
    स्पेक्स: ['./test/specs/**/*.spec.js'],
    // ...
    // define specific suites
    suites: {
        login: [
            './test/specs/login.success.spec.js',
            './test/specs/login.failure.spec.js'
        ],
        otherFeature: [
            // ...
        ]
    },
    // ...
}

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

wdio wdio.conf.js --suite login

या, एक साथ कई सुइट चलाएँ:

wdio wdio.conf.js --suite login --suite otherFeature

क्रमिक रूप से चलाने के लिए ग्रुपिंग टेस्ट स्पेक्स

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

एकल उदाहरण में चलाने के लिए समूह परीक्षणों के लिए, उन्हें स्पेक्स परिभाषा के भीतर एक सरणी के रूप में परिभाषित करें।

    "specs": [
        [
            "./test/specs/test_login.js",
            "./test/specs/test_product_order.js",
            "./test/specs/test_checkout.js"
        ],
        "./test/specs/test_b*.js",
    ],

उपरोक्त उदाहरण में, परीक्षण 'test_login.js', 'test_product_order.js' और 'test_checkout.js' एक ही उदाहरण में क्रमिक रूप से चलाए जाएंगे और प्रत्येक "test_b*" परीक्षण अलग-अलग उदाहरणों में समवर्ती रूप से चलेंगे।

सुइट्स में परिभाषित विशिष्टताओं को समूहीकृत करना भी संभव है, इसलिए अब आप सुइट्स को इस प्रकार भी परिभाषित कर सकते हैं:

    "suites": {
        end2end: [
            [
                "./test/specs/test_login.js",
                "./test/specs/test_product_order.js",
                "./test/specs/test_checkout.js"
            ]
        ],
        allb: ["./test/specs/test_b*.js"]
},

और इस मामले में "end2end" सुइट के सभी परीक्षण एक ही उदाहरण में चलाए जाएंगे।

एक पैटर्न का उपयोग करके क्रमिक रूप से परीक्षण चल ाते समय, यह वर्णानुक्रम में कल्पना फ़ाइलों को चलाएगा

  "suites": {
    end2end: ["./test/specs/test_*.js"]
  },

यह उपरोक्त पैटर्न से मेल खाने वाली फाइलों को निम्न क्रम में चलाएगा:

  [
      "./test/specs/test_checkout.js",
      "./test/specs/test_login.js",
      "./test/specs/test_product_order.js"
  ]

चयनित परीक्षण चलाएँ

कुछ मामलों में, आप अपने सुइट्स का केवल एक परीक्षण (या परीक्षणों का सबसेट) निष्पादित करना चाह सकते हैं।

--spec पैरामीटर के साथ, आप निर्दिष्ट कर सकते हैं कि कौन से सुइट (मोचा, जैस्मीन) या फीचर (कुकुम्बर) को चलाया जाना चाहिए। पथ आपकी वर्तमान कार्यशील निर्देशिका से संबंधित हल हो गया है।

उदाहरण के लिए, केवल अपना लॉगिन टेस्ट चलाने के लिए:

wdio wdio.conf.js --spec ./test/specs/e2e/login.js

या एक साथ कई स्पेक्स चलाएं:

wdio wdio.conf.js --spec ./test/specs/signup.js --spec ./test/specs/forgot-password.js

यदि --spec मान किसी विशेष युक्ति फ़ाइल को इंगित नहीं करता है, तो इसका उपयोग आपके कॉन्फ़िगरेशन में परिभाषित विशिष्ट फ़ाइल नामों को फ़िल्टर करने के लिए किया जाता है।

विशिष्ट फ़ाइल नामों में "संवाद" शब्द के साथ सभी विनिर्देशों को चलाने के लिए, आप इसका उपयोग कर सकते हैं:

wdio wdio.conf.js --spec dialog

ध्यान दें कि प्रत्येक परीक्षण फ़ाइल एकल परीक्षण रनर प्रक्रिया में चल रही है। चूंकि हम फाइलों को पहले से स्कैन नहीं करते हैं ( wdioपर फ़ाइल नामों को पाइप करने के बारे में जानकारी के लिए अगला भाग देखें), आप निर्देश देने के लिए अपनी कल्पना फ़ाइल के शीर्ष पर (उदाहरण के लिए) वर्णन.केवल उपयोग _नहीं _ कर सकते मोचा केवल उस सूट को चलाने के लिए।

यह सुविधा आपको उसी लक्ष्य को पूरा करने में मदद करेगी।

जब --spec विकल्प प्रदान किया जाता है, तो यह कॉन्फ़िगरेशन या क्षमता स्तर के specs पैरामीटर द्वारा परिभाषित किसी भी पैटर्न को ओवरराइड कर देगा।

चयनित परीक्षण चलाएँ

जरूरत पड़ने पर, यदि आपको किसी रन से विशेष विशेष फाइल (फाइलों) को बाहर करने की आवश्यकता है, तो आप --exclude पैरामीटर (मोचा, जैस्मीन) या फीचर (ककड़ी) का उपयोग कर सकते हैं।

उदाहरण के लिए, अपने लॉगिन टेस्ट को टेस्ट रन से बाहर करने के लिए:

wdio wdio.conf.js --exclude ./test/specs/e2e/login.js

या, एक से अधिक विशिष्ट फ़ाइलें बाहर करता है:

wdio wdio.conf.js --exclude ./test/specs/signup.js --exclude ./test/specs/forgot-password.js

या, एक सूट का उपयोग करते हुए फ़िल्टर करते समय एक विशिष्ट फ़ाइल को बाहर करें:

wdio wdio.conf.js --suite login --exclude ./test/specs/e2e/login.js

जब --exclude विकल्प प्रदान किया जाता है, तो यह कॉन्फ़िगरेशन या क्षमता स्तर के exclude पैरामीटर द्वारा परिभाषित किसी भी पैटर्न को ओवरराइड कर देगा।

सूट और टेस्ट स्पेक्स चलाएं

अलग-अलग विशिष्टताओं के साथ एक संपूर्ण सुइट चलाएं।

wdio wdio.conf.js --suite login --spec ./test/specs/signup.js

एकाधिक, विशिष्ट परीक्षण विशिष्टताएँ चलाएँ

निरंतर एकीकरण के संदर्भ में कभी-कभी—आवश्यक होता है और अन्यथा चलाने के लिए विशिष्टताओं के एकाधिक सेट निर्दिष्ट करने के लिए—होता है। WebdriverIO की wdio कमांड लाइन यूटिलिटी पाइप्ड-इन फ़ाइलनामों को स्वीकार करती है ( find, grep, या अन्य)।

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

grep -r -l --include "*.js" "myText" | wdio wdio.conf.js

नोट: यह नहीं _ --spec फ़्लैग को सिंगल स्पेक चलाने के लिए ओवरराइड करेगा।_

MochaOpts के साथ विशिष्ट परीक्षण चलाना

आप यह भी फ़िल्टर कर सकते हैं कि कौन स ा विशिष्ट |suite|describe और/या test| जिसे आप मोचा विशिष्ट तर्क पास करके चलाना चाहते हैं: --mochaOpts.grep wdio CLI को।

wdio wdio.conf.js --mochaOpts.grep myText
wdio wdio.conf.js --mochaOpts.grep "Text with spaces"

नोट: मोचा WDIO टेस्ट रनर के इंस्टेंस बनाने के बाद परीक्षणों को फ़िल्टर करेगा, इसलिए आप कई इंस्टेंसेस को उत्पन्न होते हुए देख सकते हैं लेकिन वास्तव में निष्पादित नहीं होते हैं।

Exclude Specific Tests with MochaOpts

You can also filter which specific suite|describe and/or it|test you want to exclude by passing a mocha specific argument: --mochaOpts.invert to the wdio CLI. --mochaOpts.invert performs opposite of --mochaOpts.grep

wdio wdio.conf.js --mochaOpts.grep "string|regex" --mochaOpts.invert
wdio wdio.conf.js --spec ./test/specs/e2e/login.js --mochaOpts.grep "string|regex" --mochaOpts.invert

Note: Mocha will filter the tests after the WDIO test runner creates the instances, so you might see several instances being spawned but not actually executed.

असफलता के बाद परीक्षण बंद करो

bail विकल्प के साथ, आप किसी भी परीक्षण के विफल होने के बाद WebdriverIO को परीक्षण बंद करने के लिए कह सकते हैं।

यह बड़े परीक्षण सूट के साथ सहायक होता है जब आप पहले से ही जानते हैं कि आपका निर्माण टूट जाएगा, लेकिन आप एक पूर्ण परीक्षण चलाने की लंबी प्रतीक्षा से बचना चाहते हैं।

bail विकल्प एक संख्या की अपेक्षा करता है, जो निर्दिष्ट करता है कि वेबड्राइवर द्वारा पूरे परीक्षण को रोकने से पहले कितने परीक्षण विफल हो सकते हैं। डिफ़ॉल्ट 0है, जिसका अर्थ है कि यह हमेशा उन सभी परीक्षणों को चलाता है जो इसे मिल सकते हैं।

जमानत विन्यास पर अतिरिक्त जानकारी के लिए कृपया विकल्प पृष्ठ देखें।

रन विकल्प पदानुक्रम

यह घोषित करते समय कि कौन से स्पेक्स को चलाना है, एक निश्चित पदानुक्रम है जो यह परिभाषित करता है कि कौन सा पैटर्न पूर्वता लेगा। वर्तमान में, यह इस तरह काम करता है, सर्वोच्च प्राथमिकता से निम्नतम तक:

CLI --spec argument > capability specs pattern > config specs pattern CLI --exclude argument > config exclude pattern > capability exclude pattern

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

क्षमता-परिभाषित कल्पना पैटर्न का उपयोग करना

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

उदाहरण के लिए, मान लें कि आपके पास दो निर्देशिकाएं हैं, जिनमें से एक Android परीक्षण के लिए है, और एक iOS परीक्षण के लिए है।

गैर-विशिष्ट उपकरण परीक्षणों के लिए आपकी कॉन्फ़िगरेशन फ़ाइल पैटर्न को इस प ्रकार परिभाषित कर सकती है:

{
    specs: ['tests/general/**/*.js']
}

लेकिन तब, आपके पास अपने Android और iOS उपकरणों के लिए अलग-अलग क्षमताएँ ह ोंगी, जहाँ पैटर्न इस तरह दिख सकते हैं:

{
  "platformName": "Android",
  "specs": [
    "tests/android/**/*.js"
  ]
}

{
  "platformName": "iOS",
  "specs": [
    "tests/ios/**/*.js"
  ]
}

यदि आपको अपनी कॉन्फ़िगरेशन फ़ाइल में इन दोनों क्षमताओं की आवश्यकता है, तो एंड्रॉइड डिवाइस केवल "एंड्रॉइड" नामस्थान के तहत परीक्षण चलाएगा, और आईओएस परीक्षण केवल "आईओएस" नामस्थान के तहत परीक्षण चलाएगा!

//wdio.conf.js
export const config = {
    "specs": [
        "tests/general/**/*.js"
    ],
    "capabilities": [
        {
            platformName: "Android",
            specs: ["tests/android/**/*.js"],
            //...
        },
        {
            platformName: "iOS",
            specs: ["tests/ios/**/*.js"],
            //...
        },
        {
            platformName: "Chrome",
            //config level specs will be used
        }
    ]
}