वेट्स और सिंक्रोनाइज़ेशन

यह क्यों ज़रूरी है

Timing flaky UI tests की एक आम वजह है: test तेज़ laptop पर pass होता है और व्यस्त CI runner पर fail, या बीस में से एक run में fail होता है। हर झूठा failure किसी की जाँच का समय लेता है, और जो team ऐसे बहुत failures देखती है वह red builds पढ़ने की बजाय उन्हें दोबारा चलाने लगती है। इसी तरह असली defect बिना ध्यान दिए निकल जाता है।

खराब waits हर run में समय भी खाते हैं, और धीमा suite कम बार चलाया जाता है। अच्छे waits suite को एक साथ तेज़ और भरोसेमंद बनाते हैं: वह application की रफ़्तार से चलता है, और fail होने पर message बताता है कि कौन-सी state कभी नहीं आई।

Test की timing और application की timing

Test और application दो अलग घड़ियों पर चलते हैं। Click जैसा command browser के उसे पूरा करते ही लौट आता है, और test अपनी अगली line पर चला जाता है। Click ने जो शुरू किया वह बाद में, application के अपने समय पर पूरा होता है: जैसा "टेस्टर्स के लिए JavaScript बेसिक्स" lesson में देखा, fetch() एक pending promise लौटाता है और page तभी बदलता है जब response आता है।

Synchronize करने के लिए test को एक ऐसी condition चाहिए जिसे वह जाँच सके: page पर, URL में या network पर कुछ ऐसा जो तभी सच हो जब application अगले step के लिए तैयार हो। आम देरी जिनके लिए plan करना होता है:

• Network requests: loading, saving और searching तब पूरे होते हैं जब server जवाब देता है।
• Rendering: कोई list या total अपना data आने के बाद दिखता है, कभी-कभी दो चरणों में (पहले placeholder, फिर values)।
• Animations: slide होकर आता dialog, या layout के सेट होते समय खिसकता button।
• Timers: search box जो आख़िरी keystroke के 300 ms बाद search करता है (debounce), या message जो 5 seconds बाद ग़ायब हो जाता है।
• Navigation: sign-in के बाद redirect, नया tab, या download।

Fixed sleep कभी इलाज क्यों नहीं है

जल्दबाज़ test को pass कराने का सबसे आसान तरीका एक pause है: Thread.sleep(3000), time.sleep(3), cy.wait(3000) या page.waitForTimeout(3000)। Sleep को पता नहीं होता कि वह किसका इंतज़ार कर रहा है; वह तय समय रुकता है और फिर आगे बढ़ जाता है, app तैयार हो या न हो। Playwright documentation समय का इंतज़ार करने वाले tests को स्वभाव से flaky कहता है, और Cypress best practices मनमाने समय तक इंतज़ार को anti-pattern मानती हैं।

धीमे endpoint के साथ आप यह समस्या खुद देख सकते हैं: API स्टेटस कोड सिम्युलेटर आपकी चुनी देरी (अधिकतम 10 seconds) के बाद जवाब देता है। Sleep तीन तरह से गलत होता है:

• धीमे run पर बहुत छोटा: व्यस्त CI runner पर payment response 3.4 seconds बाद आता है, test 3.0 पर पढ़ता है और fail होता है, पर सिर्फ़ कुछ runs में, इसलिए test flaky बन जाता है।
• तेज़ run पर बहुत लंबा: response 0.3 seconds में आ जाए तब भी test 3 seconds रुकता है। ऐसे एक-एक sleep वाले दो सौ tests हर run में कुल मिलाकर 10 मिनट कुछ किए बिना बिताते हैं।
• कोई इरादा नहीं: sleep(3000) यह नहीं बताता कि लिखने वाला किसका इंतज़ार कर रहा था, इसलिए न अगला पढ़ने वाला और न failure message बता पाता है कि कौन-सी condition मायने रखती थी।

आज़माएँ: API स्टेटस कोड सिम्युलेटर

Implicit और explicit waits

हर condition-based wait के तीन हिस्से होते हैं: condition, एक timeout जो wait को error के साथ ख़त्म करता है, और polling interval, यानी condition कितनी बार जाँची जाती है। Selenium WebDriver दो तरह के waits देता है।

Implicit wait पूरे session की एक setting है: हर element lookup तब तक retry करता है जब तक element DOM में मौजूद न हो जाए या timeout ख़त्म न हो (default 0 है, यानी तुरंत fail)। यह सिर्फ़ मौजूदगी का इंतज़ार करता है, और element मौजूद होकर भी hidden, disabled या किसी और element से ढका हो सकता है। यह उन lookups को भी धीमा करता है जिन्हें कुछ नहीं मिलना चाहिए: findElements से यह जाँचना कि error message मौजूद नहीं है, पूरा implicit timeout खा जाता है।

Explicit wait उसी step पर लिखा जाता है जिसे उसकी ज़रूरत है: timeout और condition के साथ WebDriverWait। ExpectedConditions (Python में expected_conditions) आम conditions देता है, जैसे visible, clickable, invisible, text present और URL contains, और आप अपना function भी दे सकते हैं: Java में d -> … या Python में lambda d: …, यह वही idea है जो JavaScript के arrow function में है, और d driver है। Default रूप से WebDriverWait हर 500 milliseconds पर जाँचता है और condition सच होते ही लौट आता है। Selenium documentation implicit और explicit waits मिलाने से मना करता है: दोनों timeouts आपस में उलझते हैं और कोई step दोनों values से ज़्यादा देर बाद fail हो सकता है।

// A) Implicit wait: one session-wide setting, used by every findElement call.
//    It waits until the element is present in the DOM, not visible or clickable.
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(5));

// B) Explicit wait: a condition at the step that needs it. Use B instead of A,
//    never both in the same session.
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.textToBePresentInElementLocated(
    By.cssSelector("[data-testid=payment-status]"), "Paid"));
wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("[data-testid=download-receipt]"))).click();

// Your own condition: a function the wait calls until it returns true
wait.until(d -> d.findElements(By.cssSelector("[data-testid=result-row]")).size() == 1);

Playwright और Cypress में auto-waiting

Playwright हर action से पहले actionability checks चलाता है। click() के लिए element visible, stable (हिल न रहा हो), events receive करने लायक (किसी दूसरे element से ढका न हो) और enabled होना चाहिए; fill() के लिए visible, enabled और editable। ये checks तब तक दोहराए जाते हैं जब तक pass न हों या timeout ख़त्म न हो। Assertions वाले lesson के retry करने वाले assertions expected state का इंतज़ार इसी तरह करते हैं। Locator हर इस्तेमाल पर फिर से resolve होता है, इसलिए दोबारा render हुआ element test के हाथ में पुराना reference नहीं छोड़ता, यानी वह StaleElementReferenceException जिसे Selenium users जानते हैं।

Cypress cy.get() और cy.contains() जैसी queries को उनसे जुड़े assertion के साथ retry करता है, default रूप से 4 seconds तक, और .click() या .type() से पहले element के actionable होने का इंतज़ार करता है। Server का इंतज़ार करने के लिए cy.intercept() से request को alias दें और उस alias का इंतज़ार करें, किसी number का कभी नहीं।

Auto-waiting यह जाँचता है कि element इस्तेमाल हो सकता है, यह नहीं कि application तैयार है। "Pay now" button order total load होने से पहले ही enabled हो सकता है, और Playwright उस पर click कर देगा। जब step किसी data पर निर्भर हो, तो पहले उस data को assert करें। Response का इंतज़ार करना हो तो request भेजने वाले action से पहले सुनना शुरू करें, वरना तेज़ response wait शुरू होने से पहले ही आ सकता है। Playwright documentation tests में networkidle state का इंतज़ार करने को भी discourage करता है।

// Playwright: click() waits until the button is visible, stable, receives
// events and is enabled; toHaveText() retries until it matches (5 s default).
await page.getByRole('button', { name: 'Pay now' }).click();
await expect(page.getByTestId('payment-status')).toHaveText('Paid');

// Playwright: to wait for the server, start listening before the click.
const response = page.waitForResponse('**/api/payments');
await page.getByRole('button', { name: 'Pay now' }).click();
expect((await response).status()).toBe(201);

// Cypress: queries retry with their assertion (4 s default);
// an intercept alias waits for the request instead of a number.
cy.intercept('POST', '/api/payments').as('pay');
cy.contains('button', 'Pay now').click();
cy.wait('@pay');
cy.get('[data-testid=payment-status]').should('have.text', 'Paid');

Worked example: flaky payment test ठीक करना

Payment page का एक Playwright test लगभग दस में से एक pipeline run में Expected: "Paid", Received: "Processing" के साथ fail होता है; लिखने वाले के laptop पर वह हमेशा pass होता है। Trace दिखाता है कि status click के 3.0 seconds बाद पढ़ा गया और payment response 3.4 पर आया। Page order total भी page के बाद load करता है, और पहला sleep इसी को ढक रहा था।

Fix हर sleep को उस condition से बदलता है जिसका वह अंदाज़ा लगा रहा था। Team ने shared staging environment पर payment step नापा: आम तौर पर एक second से कम, सबसे बुरी हालत में लगभग 8 seconds। यही measurement अकेले लंबे timeout को तय करता है। किसी public endpoint के लिए रिस्पॉन्स टाइम एनालाइज़र इसी तरह का data देता है: कई samples पर median, maximum और p95 (वह समय जिसके अंदर 95% samples रहे)।

• [1] पहला sleep दिखने वाले total, 172.50 SAR, पर assertion बन जाता है। यह बताता है कि "load हो गया" का मतलब क्या है, और गलत total भी पकड़ता है।
• [2] और [3] एक retry करने वाला assertion बन जाते हैं। सामान्य run में यह click के एक second के अंदर आगे बढ़ जाता है; सिर्फ़ इसी step को 15 seconds तक की छूट है, और comment उसकी वजह दर्ज करता है।
• आख़िरी click को अलग wait नहीं चाहिए: Playwright "Download receipt" के enabled होने तक इंतज़ार करता है।
• अगर बाद में payment को 15 seconds से ज़्यादा लगने लगे, तो timeout फिर बढ़ाने की बजाय timings के साथ इसे performance problem के रूप में report करें।

// BEFORE: always passes locally, fails in about one CI run in ten
await page.goto('/orders/1042/pay');
await page.waitForTimeout(2000);                    // [1] "let the total load"
await page.getByRole('button', { name: 'Pay now' }).click();
await page.waitForTimeout(3000);                    // [2] "let the payment finish"
const status = await page.getByTestId('payment-status').textContent();
expect(status).toBe('Paid');                        // [3] reads once
await page.getByRole('button', { name: 'Download receipt' }).click();

// AFTER: each sleep replaced by the condition it was guessing at
await page.goto('/orders/1042/pay');
await expect(page.getByTestId('order-total')).toHaveText('172.50 SAR');       // [1]
await page.getByRole('button', { name: 'Pay now' }).click();
// [2] + [3]: payment sandbox measured at up to 8 s on shared staging
await expect(page.getByTestId('payment-status'))
  .toHaveText('Paid', { timeout: 15_000 });
await page.getByRole('button', { name: 'Download receipt' }).click();   // auto-waits

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Waiting Strategies — SeleniumSelenium Projectब्राउज़र टेस्ट पेज से race क्यों करते हैं, और implicit व explicit waits WebDriver स्क्रिप्ट को ऐप के साथ कैसे सिंक करते हैं।
• Auto-waiting — PlaywrightMicrosoft (Playwright)हर एक्शन से पहले Playwright की actionability जाँचें — visible, stable, enabled, events प्राप्त करने योग्य — जो ज़्यादातर हाथ से लिखे wait की ज़रूरत हटाती हैं।
• Best Practices — CypressCypress.ioसमर्पित एट्रिब्यूट से एलिमेंट चुनने, फ़िक्स्ड wait से बचने और टेस्ट को स्वतंत्र रखने पर Cypress की गाइडेंस।
• WebDriver (W3C)W3C · 2026वह W3C प्रोटोकॉल जिसे ब्राउज़र Selenium जैसे ऑटोमेशन टूल से रिमोट कंट्रोल के लिए लागू करते हैं (Level 2 संस्करण Working Draft है)।