Puppeteer के साथ UI Testing: व्यावहारिक गाइड

Puppeteer के साथ UI testing वाकई किन चीज़ों में अच्छा है

• सीधा browser नियंत्रण। Screenshots, PDFs, network interception, performance traces। जब आपको browser से कुछ खास करवाना हो, तो यह सबसे छोटा रास्ता है।

• Scraping और automation। Puppeteer का एक बड़ा हिस्सा testing के लिए इस्तेमाल होता ही नहीं, और इन कामों में यह शानदार है।

• छोटा, आसानी से सीखा जा सकने वाला surface। पूरा API आपके दिमाग में समा सकता है, जो जितना आम होना चाहिए उतना आम नहीं है।

एक browser suite की तीन लागतें

• Selectors टूटते हैं। ऐसा redesign जो कार्यात्मक रूप से कुछ नहीं बदलता, वह भी पूरी suite को लाल कर देता है। असल में maintenance का ज़्यादातर समय यहीं जाता है।

• इंतज़ार करना बारीक मामला है। तय delay धीमे होते हैं और फिर भी flaky रहते हैं; सही wait के लिए यह जानना ज़रूरी है कि इंतज़ार किस चीज़ का करना है। ज़्यादातर flakiness की जड़ यहीं है।

• Coverage हाथ से लिखी जाती है। आपके पास उतनी ही coverage होती है जितनी किसी ने लिखी — यानी वे flows जो दिलचस्प लगे, न कि वे जो टूटते हैं।

क्या automate करना है, यह तय करना

सहज प्रवृत्ति यही होती है कि सबसे ज़रूरी feature से शुरुआत करें। बेहतर कसौटी यह है कि कोई चीज़ कितनी चुपचाप फेल होगी। Checkout का टूटना शोर मचाता है और एक घंटे के भीतर आपको इसकी खबर मिल जाएगी। किसी export, invite या settings page का टूटना चुपचाप होता है, और चुपचाप होने वाली विफलताएँ ही पहले automate करने लायक हैं।

दूसरी कसौटी: वह कितनी बार बदलता है। जो flow हर sprint में बदलता है, उसका maintenance उससे मिलने वाले फायदे से ज़्यादा महंगा पड़ेगा। उसे बाद में cover करें, जब वह स्थिर हो जाए।

तीन आदतें जो सबसे ज़्यादा समय बचाती हैं

• स्थिर attributes इस्तेमाल करें। CSS path के बजाय एक समर्पित test attribute। यह अकेला बदलाव redesign से होने वाली ज़्यादातर टूट-फूट खत्म कर देता है।

• समय का नहीं, state का इंतज़ार करें। element या response का इंतज़ार करें, कभी कुछ milliseconds का नहीं।

• ऐसी चीज़ पर assert करें जिसकी पुष्टि एक reload कर दे। success toast इस बात का सबूत नहीं है कि कुछ सचमुच सेव हुआ।

इरादे-आधारित verification कहाँ फिट बैठता है

Selector का टूटना और हाथ से लिखी coverage — ये संरचनात्मक बातें हैं, बेहतर अनुशासन से ठीक होने वाली नहीं। इरादे के रूप में लिखा गया step उस redesign को झेल जाता है जिसे कोई selector नहीं झेल पाता, और जो coverage किसी की याददाश्त के बजाय आपके प्रोडक्ट से तैयार होती है, उसमें वे flows भी आ जाते हैं जिन्हें कोई नहीं लिखता।

यह Puppeteer के खिलाफ तर्क नहीं है — सीधे browser नियंत्रण के लिए वह अब भी सही टूल है। यह तर्क इस बात का है कि चौड़ाई हाथ से न लिखी जाए।

अगर आप कुछ भी install नहीं करना चाहते, तो dashboard भी यही काम करता है। command line और जो कुछ कर सकती है, उस सबके लिए देखें CLI रिपॉज़िटरी।

तीन चीज़ें जो किसी Puppeteer script को नाज़ुक बना देती हैं

जल्दबाज़ी में लिखी गई scripts इन्हीं तीन वजहों से टूटती हैं, और हर एक का ऐसा हल है जो अभी अपनाने पर कुछ नहीं लेता और बाद में बहुत महंगा पड़ता है।

पहली है chained CSS paths। जो selector structure की चार परतों से होकर गुज़रता है, वह element नहीं बल्कि layout को दर्ज करता है, इसलिए कोई भी नया wrapper उसे तोड़ देता है। ऐसी चीज़ पर टिकें जो बताए कि element क्या है, न कि वह कहाँ बैठा है।

दूसरी है fixed waits। जो delay किसी धीमे दिन भरोसेमंद रहने लायक लंबा है, वही delay आप हर तेज़ दिन चुकाते हैं — और सबसे धीमे दिन वह फिर भी फेल हो जाता है। element, response या state बदलने का इंतज़ार करें।

तीसरी है उसी चीज़ पर assert करना जो आपने अभी-अभी की है। save पर click करके फिर यह जाँचना कि save button मौजूद है, कुछ साबित नहीं करता। Assertion ऐसी होनी चाहिए जो तभी सच हो जब operation वाकई पूरा हुआ हो — और इसका मतलब आमतौर पर उस चीज़ को वापस fetch करना होता है।

हर बदलाव पर इसे चलाएँ

अगर pipeline किसी दूसरी टीम की है, तो GitHub App सबसे कम रुकावट वाला रास्ता है: यह एक webhook है, आपकी repository में कुछ नहीं बदलता, और तब चलता है जब आपका build नए version के live होने की सूचना देता है। अगर आप चाहते हैं कि check repo में ही दिखे, तो GitHub Actions का एक step यह काम कर देता है।

Puppeteer के साथ-साथ TestSprite कहाँ फिट बैठता है

सीधे browser नियंत्रण के लिए Puppeteer बना रहता है: screenshots, PDFs, network interception, scraping। TestSprite वह हिस्सा संभालता है जो लिखने वाले के समय के साथ scale नहीं करता — यानी यह तय करना कि किसे cover किया जाए और उसे ज़िंदा रखना।

Steps selectors के बजाय इरादों के रूप में सहेजे जाते हैं, जिससे redesign से होने वाली ज़्यादातर टूट-फूट खत्म हो जाती है, और इंतज़ार अपने आप संभल जाता है — हर test के लिए उसे ट्यून नहीं करना पड़ता। Coverage आपके प्रोडक्ट से तैयार होती है, इसलिए वे चुपचाप रहने वाले flows भी इसमें शामिल होते हैं जो कभी किसी की सूची में नहीं आते।

व्यवहार में इससे क्या बदलता है: लाल builds में असली bugs का अनुपात इतना ऊँचा बना रहता है कि लोग उन्हें पढ़ते रहते हैं — और यही असल में तय करता है कि कोई browser suite अपने दूसरे साल तक टिकेगी या नहीं।