टेस्ट सूट को व्यवस्थित करना

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

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

पूरे सूट को बाहर करें

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

wdio wdio.conf.js --suite login --suite checkout --exclude login

यह केवल checkout सूट चलाएगा, login सूट को पूरी तरह से छोड़कर।

मिश्रित बहिष्करण (सूट्स और स्पेक पैटर्न) अपेक्षित रूप से काम करते हैं:

wdio wdio.conf.js --suite login --exclude dialog --exclude signup

इस उदाहरण में, यदि signup एक परिभाषित सूट नाम है, तो उस सूट को बाहर रखा जाएगा। पैटर्न dialog किसी भी स्पेक फाइल को फ़िल्टर करेगा जिसमें उनके फाइलनाम में "dialog" है।

नोट

यदि आप --suite X और --exclude X दोनों निर्दिष्ट करते हैं, तो बहिष्करण प्राथमिकता लेता है और सूट X नहीं चलेगा।

जब --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 और/या it|test आप wdio CLI को एक विशेष मोचा आर्गुमेंट पास करके चलाना चाहते हैं: --mochaOpts.grep।

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

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

MochaOpts के साथ विशिष्ट टेस्ट को बाहर करें

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