परीक्षण सूट व्यवस्थित करना

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

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

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

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

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

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

// wdio.conf.js
export const config = {
    // ...
    // 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'
    }],
    // ...
}

मुख्य कॉन्फिग फाइल से विरासत में प्राप्त करें

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

पेज ऑब्जेक्ट कॉन्सेप्ट के समान, पहली चीज जिसकी आपको आवश्यकता होगी वह है एक मुख्य कॉन्फिग फाइल। इसमें वे सभी कॉन्फिगरेशन शामिल हैं जिन्हें आप वातावरणों में साझा करते हैं।

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

// 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
export const config = {
    // define all tests
    specs: ['./test/specs/**/*.spec.js'],
    // ...
    // define specific suites
    suites: {
        login: [
            './test/specs/login.success.spec.js',
            './test/specs/login.failure.spec.js'
        ],
        otherFeature: [
            // ...
        ]
    },
    // ...
}

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

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 पैरामीटर के साथ, आप निर्दिष्ट कर सकते हैं कि कौन सा suite (Mocha, Jasmine) या feature (Cucumber) चलाया जाना चाहिए। पथ आपकी वर्तमान कार्य निर्देशिका से सापेक्ष रूप से हल किया जाता है।

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

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 मान किसी विशेष स्पेक फ़ाइल की ओर इशारा नहीं करता है, तो इसके बजाय आपके कॉन्फिगरेशन में परिभाषित स्पेक फ़ाइलनाम को फ़िल्टर करने के लिए उपयोग किया जाता है।

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

wdio wdio.conf.js --spec dialog

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

यह फ़ीचर आपको समान लक्ष्य को पूरा करने में मदद करेगा।

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

चयनित परीक्षण बाहर रखें

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

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

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 मान किसी विशेष स्पेक फ़ाइल की ओर इशारा नहीं करता है, तो इसके बजाय आपके कॉन्फिगरेशन में परिभाषित स्पेक फ़ाइलनाम को फ़िल्टर करने के लिए उपयोग किया जाता है।

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

wdio wdio.conf.js --exclude dialog

जब --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 के साथ विशिष्ट परीक्षण चलाना

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

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

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

MochaOpts के साथ विशिष्ट परीक्षण बाहर रखें

आप mocha विशिष्ट तर्क: --mochaOpts.invert wdio CLI में पास करके किस विशिष्ट suite|describe और/या it|test को बाहर रखना चाहते हैं, यह फ़िल्टर भी कर सकते हैं। --mochaOpts.invert --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

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

विफलता के बाद परीक्षण बंद करें

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

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

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

बेल कॉन्फिगरेशन पर अतिरिक्त जानकारी के लिए कृपया विकल्प पृष्ठ देखें।

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

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

CLI --spec आर्गुमेंट > क्षमता specs पैटर्न > कॉन्फिग specs पैटर्न CLI --exclude आर्गुमेंट > कॉन्फिग exclude पैटर्न > क्षमता exclude पैटर्न

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

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

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

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

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

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

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

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

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

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

//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
        }
    ]
}