बीते समय की एक झलक: टेस्ट ऑटोमेशन का बेहतर इस्तेमाल

Jecelyn Yeen

Maksim Sadym

टेस्ट ऑटोमेशन का जन्म

आइए, 1990 के दशक में जाएं, जब वेब ब्राउज़र की शुरुआत हुई थी. साल 2000 के दशक तक, टेस्ट ऑटोमेशन काम नहीं कर पाया. इसलिए, क्रॉस-ब्राउज़र और मल्टी-डिवाइस टेस्टिंग की चुनौतियों से निपटने के लिए Selenium और WebDriver प्रोजेक्ट की शुरुआत हुई.

इन दोनों प्रोजेक्ट को साल 2011 में Selenium WebDriver के तौर पर जोड़ा गया था. साल 2018 में, ये W3C स्टैंडर्ड बन गए. आम तौर पर, हम इसे WebDriver या WebDriver का “क्लासिक” कहते हैं.

WebDriver के “क्लासिक” वर्शन से पहले, ऑटोमेशन की जांच करना काफ़ी मुश्किल था. ब्राउज़र टेस्टिंग को ऑटोमेट करने से, डेवलपर और टेस्टर की क्वालिटी बेहतर हुई है.

JavaScript का उदय

वेब डेवलपमेंट के दौरान JavaScript का ज़्यादा इस्तेमाल करने की शुरुआत होने के बाद, WebdriverIO, Appium, Nightwatch, Proट्रैक्टर (अब सेवा में नहीं आने वाले), Testcafe, Cypress, Puppeteer, और Playwright जैसे नए ऑटोमेशन समाधान उभरकर सामने आए.

ऑटोमेशन की प्रोसेस

मोटे तौर पर, इन टूल को दो मुख्य ग्रुप में बांटा जा सकता है, जो इस आधार पर तय होते हैं कि ये ब्राउज़र को ऑटोमेट कैसे करते हैं:

• हाई लेवल: ऐसे टूल जो ब्राउज़र में JavaScript का इस्तेमाल करते हैं. उदाहरण के लिए, Cypress और TestCafe, ब्राउज़र में टेस्ट चलाने के लिए वेब एपीआई और Node.js का इस्तेमाल करते हैं. मज़ेदार जानकारी—Selenium के पहले वर्शन में भी यही तरीका इस्तेमाल किया गया था.
• कम लेवल: ऐसे टूल जो ब्राउज़र के बाहर रिमोट निर्देश लागू करते हैं. जब टूल को कई टैब खोलने या डिवाइस मोड को सिम्युलेट करने जैसे बेहतर कंट्रोल की ज़रूरत होती है, तब उन्हें प्रोटोकॉल से ब्राउज़र को कंट्रोल करने के लिए, रिमोट कमांड की ज़रूरत पड़ती है. दो मुख्य ऑटोमेशन प्रोटोकॉल हैं, WebDriver “क्लासिक” और Chrome DevTools प्रोटोकॉल (CDP).

अगले सेक्शन में, हम इन दोनों प्रोटोकॉल की क्षमताओं और सीमाओं को समझने के लिए उनके बारे में बताएंगे.

WebDriver "क्लासिक" बनाम Chrome DevTools प्रोटोकॉल (सीडीपी)

WebDriver "क्लासिक" एक वेब मानक है, जो सभी बड़े ब्राउज़र पर काम करता है. ऑटोमेशन स्क्रिप्ट, ड्राइवर सर्वर को एचटीटीपी अनुरोधों के ज़रिए निर्देश देती हैं. इसके बाद, ब्राउज़र के साथ इंटरनल प्रोटोकॉल के ज़रिए जानकारी देती हैं.

हालांकि, इसमें क्रॉस-ब्राउज़र की सुविधा बेहतरीन है और इसके एपीआई, टेस्टिंग के लिए डिज़ाइन किए गए हैं. हालांकि, यह धीमा हो सकता है और कुछ लो-लेवल के कंट्रोल पर काम नहीं करता.

उदाहरण के लिए, मान लें कि आपके पास एक टेस्ट स्क्रिप्ट है, जो await coffee.click(); एलिमेंट पर क्लिक करती है. इसका अनुवाद, एचटीटीपी अनुरोधों की सीरीज़ में किया जाता है.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

वहीं दूसरी ओर, शुरुआत में Chrome DevTools प्रोटोकॉल (सीडीपी) को Chrome DevTools और डीबग करने के लिए डिज़ाइन किया गया था. हालांकि, ऑटोमेशन के लिए Puppeteer ने इसे अपनाया. सीडीपी, WebSocket कनेक्शन के ज़रिए, Chromium पर आधारित ब्राउज़र के साथ सीधे संपर्क करता है. इससे, बेहतर परफ़ॉर्मेंस और लो-लेवल पर कंट्रोल मिलता है.

हालांकि, यह सिर्फ़ Chromium पर काम करने वाले ब्राउज़र के साथ काम करता है और यह एक ओपन स्टैंडर्ड नहीं है. सबसे बड़ी बात, सीडीपी एपीआई ज़्यादा जटिल है. कुछ मामलों में, सीडीपी के साथ काम करने के काम आसान नहीं होते. उदाहरण के लिए, 'आउट-ऑफ़-प्रोसेस iframe' के साथ काम करने में बहुत मेहनत लगती है.

उदाहरण के लिए, await coffee.click(); एलिमेंट पर क्लिक करने पर, सीडीपी कमांड की सीरीज़ बदल जाती है.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

लो-लेवल कंट्रोल क्या हैं?

जिन दिनों WebDriver “क्लासिक” बनाया गया था उन दिनों में, कम स्तर के कंट्रोल की ज़रूरत नहीं होती थी. हालांकि, अब समय बदल गया है, वेब पर अब काफ़ी बेहतर तरीके से काम किया जा सकता है. साथ ही, मौजूदा समय में की जा रही टेस्टिंग के लिए ज़्यादा सटीक और बारीकी से काम करने की ज़रूरत होती है.

सीडीपी को डीबग करने की सभी ज़रूरतों को पूरा करने के लिए डिज़ाइन किया गया था. इसलिए, यह WebDriver के “क्लासिक” वर्शन के मुकाबले कम लेवल के कंट्रोल के साथ काम करता है. यह नीचे बताई गई सुविधाओं को हैंडल कर सकता है:

• कंसोल मैसेज को कैप्चर किया जा रहा है
• नेटवर्क अनुरोधों में रुकावट डालना
• डिवाइस मोड को सिम्युलेट किया जा रहा है
• भौगोलिक स्थान की नकल की जा रही है
• और ज़्यादा!

WebDriver “क्लासिक” वर्शन में ऐसा करना मुमकिन नहीं था, क्योंकि WebDriver “क्लासिक” एचटीटीपी पर आधारित है. इससे ब्राउज़र इवेंट की सदस्यता लेना और उन्हें सुनना मुश्किल हो जाता है. दूसरी ओर, सीडीपी WebSocket पर आधारित है. यह डिफ़ॉल्ट रूप से, दो-तरफ़ा मैसेज सेवा के साथ काम करता है.

आगे क्या है: WebDriver BiDi

WebDriver के “क्लासिक” और सीडीपी, दोनों वर्शन की खूबियों के बारे में खास जानकारी यहां दी गई है:

WebDriver BiDi का मकसद WebDriver "क्लासिक" और सीडीपी के सबसे अच्छे पहलुओं को एक साथ जोड़ना है. यह एक नया स्टैंडर्ड ब्राउज़र ऑटोमेशन प्रोटोकॉल है, जिस पर अभी काम चल रहा है.

WebDriver BiDi प्रोजेक्ट के बारे में ज़्यादा जानें. इसके काम करने का तरीका, विज़न, और स्टैंडर्डाइज़ेशन की प्रोसेस क्या है.