Flaky टेस्ट

Flaky टेस्ट क्या है, और यह क्यों मायने रखता है

टेस्ट तब flaky है जब उसी commit और उसी environment configuration पर बार-बार चलाने से अलग-अलग नतीजे आएँ। दस बार चलाएँ तो शायद आठ pass और दो fail मिलें। नतीजा non-deterministic है, इसलिए अकेला कोई भी नतीजा प्रोडक्ट के बारे में ज़्यादा नहीं बताता।

इसकी लागत इसकी आवृत्ति से कहीं ज़्यादा है। हर flaky failure किसी की जाँच या rerun लेता है; कुछ बार ऐसा होने के बाद टीम हर failure को शोर मानने लगती है। Martin Fowler का non-determinism पर लेख सीधे कहता है: जो suite बेतरतीब ढंग से fail होता है वह signal के रूप में अपना मूल्य खो देता है। और flaky टेस्ट हमेशा ख़राब टेस्ट नहीं होता — कभी-कभी race condition प्रोडक्ट में ही होती है, और टेस्ट अकेला है जिसने उसे पकड़ा।

• वही टेस्ट एक रन में fail और rerun में pass होता है, बीच में कोड में कोई बदलाव नहीं।
• यह सिर्फ़ CI में, सिर्फ़ parallel में, दिन के कुछ ख़ास समय पर, या सिर्फ़ एक ब्राउज़र में fail होता है।
• Failure message रनों के बीच बदलता है — एक में timeout, अगले में “element not found”।

Flaky UI टेस्ट के आम कारण

• Timing और asynchrony — पेज तैयार होने से पहले action या assertion: अभी disabled बटन पर क्लिक, API response आने से पहले text पढ़ना, या ऐसा fixed sleep जो कभी-कभी छोटा पड़ जाता है।
• Shared state और टेस्ट का क्रम — ऐसे टेस्ट जो किसी दूसरे टेस्ट के बनाए या बदले डेटा या browser state पर निर्भर हैं। एक क्रम में pass, दूसरे में fail, या अकेले चलाने पर fail।
• टेस्ट डेटा की टक्कर — parallel टेस्ट जो एक ही account, एक ही email या एक ही product stock इस्तेमाल करते हैं; uniqueness constraints जो तब fail होते हैं जब दो रन एक ही “random” value चुन लेते हैं।
• Environment — ओवरलोडेड CI runner, रन के बीच redeploy होता shared staging environment, धीमा container start-up, या runner पर अलग screen size, locale या time zone।
• Third-party और remote services — payment sandboxes, SMS gateways, map tiles, feature-flag services और CDNs जो धीमे, अनुपलब्ध या rate-limited हों।
• Animations और transitions — किसी एलिमेंट के खिसककर अपनी जगह आते समय उस पर क्लिक, या कुछ सेकंड में ग़ायब होने वाले toast message पर assertion।
• समय और तारीख़ें — आधी रात, महीने के अंत और daylight-saving बदलावों के आसपास टूटने वाले टेस्ट, या जब runner का time zone ऐप के time zone से अलग हो।
• बिना क्रम का डेटा — उस list की पहली row पर assertion जिसे server किसी तय क्रम में नहीं लौटाता।
• Resource leaks — ब्राउज़र, sessions या database connections बंद न होना, जिससे लंबे रन में बाद के टेस्ट धीमे या fail होते हैं।
• प्रोडक्ट के असली defects — race conditions, double submissions, invalidate न होने वाले caches। ये रिपोर्ट करने लायक bugs हैं, quarantine करने लायक test noise नहीं।

लक्षण और root causes: worked examples

यह टेबल आम flaky लक्षणों को, जैसे वे defect tracker में दिखते हैं, जाँच में मिले root cause और उसे हटाने वाले fix के साथ जोड़ती है। ध्यान दें कि कोई भी fix “लंबा sleep जोड़ें” या “retries चालू करें” नहीं है।

• checkout.spec: “Place order” क्लिक लगभग 10 में से 1 रन में अनदेखा → कारण: कीमत दोबारा गिनने के बाद ही बटन enabled होता है → fix: enabled state assert करें और auto-wait पर भरोसा करें।
• orders.spec सिर्फ़ refunds.spec के बाद चलने पर fail → कारण: refunds.spec साझा order cancel कर देता है → fix: हर टेस्ट API से अपना order ख़ुद बनाए।
• signup.spec: parallel CI रनों में “email already registered” → कारण: दो workers एक ही email generate करते हैं → fix: generated डेटा में run/worker id और UUID जोड़ें।
• report.spec रियाद समय के अनुसार 00:00 से 03:00 के बीच fail → कारण: runner UTC इस्तेमाल करता है, इसलिए “आज” की तारीख़ अलग है → fix: clock कंट्रोल करें या तारीख़ें एक ही time zone में निकालें।
• profile.spec: “Saved” toast सिर्फ़ CI में नहीं मिलता → कारण: धीमे assertion से पहले toast ग़ायब हो जाता है → fix: अस्थायी toast के बजाय saved state assert करें।
• map.spec parallel load में time out → कारण: third-party map tile service रन को rate-limit करती है → fix: map responses stub करें और एक contract check रखें।

For example (fictional):

Symptom (as a bug title)                                         Root cause                                  Fix
checkout.spec: "Place order" click ignored in ~1 of 10 runs      Button enabled only after price recalculated  Assert the enabled state; rely on auto-wait
orders.spec fails only when run after refunds.spec               refunds.spec cancels the shared order         Each test creates its own order via the API
signup.spec: "email already registered" in parallel CI runs      Two workers generate the same email           Add run/worker id + UUID to generated data
report.spec fails between 00:00 and 03:00 Riyadh time            Runner uses UTC, so "today" differs           Control the clock or compute dates in one zone
profile.spec: "Saved" toast not found on CI only                 Toast disappears before the slow assertion    Assert the saved state, not the transient toast
map.spec times out under parallel load                           Third-party tile service rate-limits the run  Stub map responses; keep one contract check

Flaky टेस्ट की जाँच

Flaky टेस्ट को किसी भी intermittent bug की तरह लें: उसे reproduce करें, fail हुए रनों से सबूत इकट्ठा करें, और एक बार में एक variable बदलें जब तक failure rate न हिले।

• दोहराकर reproduce करें — एक टेस्ट को कई बार चलाएँ (Playwright में --repeat-each है; दूसरे runners में उनका repeat option या shell loop)। Failure rate “कभी-कभी fail होता है” को एक संख्या में बदल देता है जिसे fix से पहले और बाद में तुलना कर सकें।
• एक condition बदलें — अकेले बनाम पूरे suite में, serial बनाम parallel, अलग क्रम, local बनाम CI, throttled CPU या network, दूसरा ब्राउज़र। जो condition failure rate बदलती है वही कारण की ओर इशारा करती है।
• Fail हुए रन का सबूत पढ़ें — failure पर screenshot, video और trace। Playwright का trace viewer हर action को DOM snapshots, network requests और console messages के साथ दिखाता है; Cypress रनों के screenshots और videos ले सकता है; Selenium में अपने runner के failure hook में screenshot, browser logs और page source कैप्चर करें।
• Back end से मिलाएँ — टेस्ट के बनाए request ids और timestamps log करें और server logs में वही समय-खिड़की देखें। Time zones का ध्यान रखें: CI runners अक्सर UTC इस्तेमाल करते हैं जबकि ऐप local time में log करता है।
• History देखें — test reports और CI dashboards दिखाते हैं कि टेस्ट कब से flaky हुआ; उस तारीख़ की तुलना commits, dependency upgrades और environment बदलावों से करें।

// playwright.config.ts — keep evidence from failing runs
export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  use: {
    trace: "on-first-retry",
    screenshot: "only-on-failure",
    video: "retain-on-failure",
  },
});

# reproduce locally: run one spec 50 times with 4 workers
npx playwright test tests/checkout.spec.ts --repeat-each=50 --workers=4

# open the trace from a failed CI run
npx playwright show-trace trace.zip

आम कारणों को ठीक करना

• Timing — sleeps को condition-आधारित waits से बदलें: Selenium में explicit waits, Playwright में auto-waiting actions और web-first assertions, Cypress में .should() के साथ retry होने वाली queries। ऐप के अपने signal — कोई response या state बदलाव — का इंतज़ार करें, समय का नहीं।
• Shared state — हर टेस्ट अपना डेटा और browser state ख़ुद बनाए, नए browser context से शुरू करे, और कभी इस पर निर्भर न रहे कि कोई दूसरा टेस्ट पहले चला।
• डेटा की टक्कर — हर टेस्ट और हर worker के लिए unique values generate करें; parallel रनों से fixed “test user 1” जैसे accounts हटाएँ।
• Environment — browser और dependency versions pin करें, suite को dedicated environment दें या रन के दौरान deployments रोकें, और workers की संख्या के हिसाब से CI runners का आकार रखें।
• Third-party services — ज़्यादातर UI टेस्ट में उन्हें stub करें (Playwright में page.route, Cypress में cy.intercept, या mock server) और असली sandbox के ख़िलाफ़ एक छोटी, अलग रिपोर्ट होने वाली जाँच रखें।
• Animations — किसी अस्थायी state के बजाय अंतिम state assert करें; जहाँ ऐप reduced-motion preference मानता है, टेस्ट में उसे emulate करें ताकि transitions छोटे हों या हट जाएँ।
• समय — clock को कंट्रोल करें (Playwright की clock API, Cypress में cy.clock) या अपेक्षित तारीख़ें ऐप के time zone में निकालें।
• क्रम — assert करने से पहले साफ़ तौर पर sort या filter करें; कभी न मानें कि पहली row वही है जो आपके टेस्ट ने बनाई।

// Flaky: guesses how long the save takes, then reads the text once
await page.getByRole("button", { name: "Save" }).click();
await page.waitForTimeout(2000);
expect(await page.getByTestId("status").textContent()).toBe("Saved");

// Stable: waits for the app’s own signal and retries the assertion
const saved = page.waitForResponse(
  (r) => r.url().includes("/api/profile") && r.request().method() === "PUT");
await page.getByRole("button", { name: "Save" }).click();
expect((await saved).ok()).toBeTruthy();
await expect(page.getByTestId("status")).toHaveText("Saved");

आज़माएँ: फ़ेक यूज़र जनरेटर आज़माएँ: टेस्ट डेटा फ़ैक्टरी आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: API रिक्वेस्ट बिल्डर

Retries और quarantine: containment, इलाज नहीं

Automatic retries — Playwright की retries setting, Cypress का retries option, और TestNG व Maven Surefire जैसे runners के rerun features — flaky टेस्ट के बाद वाली कोशिश में pass होने पर pipeline को हरा कर देते हैं। Short-term containment के रूप में यह ठीक है और नीति के रूप में नुक़सानदेह: retries असली intermittent defects छिपाते हैं, pipeline धीमी करते हैं, और flaky rate को चुपचाप बढ़ने देते हैं। इस्तेमाल करें तो उन्हें दिखाई देने वाला बनाएँ; उदाहरण के लिए Playwright ऐसे टेस्ट को जो fail होकर retry में pass हुआ, “passed” नहीं बल्कि “flaky” रिपोर्ट करता है।

Quarantine दूसरा containment टूल है: किसी जाने-पहचाने flaky टेस्ट को merge रोकने वाले suite से निकालकर एक अलग, non-blocking job में रखें, जहाँ वह merges रोके बिना चलता और रिपोर्ट करता रहे। Fowler quarantine को main suite को भरोसेमंद रखने का तरीक़ा बताते हैं — इस चेतावनी के साथ कि quarantined टेस्ट जल्दी ठीक होने चाहिए, वरना वे किसी चीज़ की रक्षा नहीं करते।

• CI में ज़्यादा से ज़्यादा एक retry और local में कोई नहीं, और “retry में pass” को flaky के रूप में रिपोर्ट करें।
• पहले जाँचें कि failure प्रोडक्ट bug तो नहीं; असली defect को कभी quarantine न करें।
• हर quarantined टेस्ट को owner, ticket और due date दें, और सूची की हर हफ़्ते review करें।
• Quarantine में due date पार होने पर टेस्ट ठीक करें, निचले लेवल पर दोबारा लिखें, या हटा दें। हमेशा skip रहने वाला टेस्ट dead code है जो coverage जैसा दिखता है।
• Quarantine की सीमा तय करें। अगर यह बढ़ती रहे, तो इसमें जोड़ना बंद करें और साझा कारण ठीक करें — आमतौर पर environment या test data रणनीति।
• नीचे की उदाहरण नीति ठोस संख्याएँ जोड़ती है, जिन्हें अपनी टीम के हिसाब से बदला जा सकता है: जो टेस्ट उसी commit पर fail और pass दोनों हो, CI उसे flaky flag करता है; 1 working day में triage (प्रोडक्ट bug, टेस्ट bug या environment?); quarantine की due date ज़्यादा से ज़्यादा 10 working days; quarantine से बाहर तब, जब टेस्ट ठीक होकर --repeat-each के साथ लगातार 50 बार pass हो, या दोबारा लिखा या हटा दिया जाए; और हर हफ़्ते flaky सूची व हर suite के flaky-rate trend की review।

Flaky test policy (example)
- Detection:  a test that fails and passes on the same commit is flagged flaky by CI
- Retries:    at most 1 in CI, 0 locally; "passed on retry" is reported as flaky, not passed
- Triage:     within 1 working day: product bug, test bug or environment?
- Quarantine: non-blocking job, with ticket + owner + due date (max 10 working days)
- Exit:       fixed and 50 consecutive passes with --repeat-each, or rewritten / deleted
- Review:     weekly flaky list in the QA sync; flaky-rate trend per suite

Ownership और माप

जिन flaky टेस्ट का कोई owner नहीं, वे flaky ही रहते हैं। Ownership प्रोडक्ट क्षेत्र के हिसाब से दें — जो टीम checkout की मालिक है वही checkout टेस्ट की — किसी एक “automation person” को नहीं, और flaky-test triage को side project के बजाय सामान्य definition of done का हिस्सा बनाएँ।

कुछ सरल माप दिखाते हैं कि हालात सुधर रहे हैं या नहीं। इन्हें हर suite के लिए ट्रैक करें और एक हफ़्ते के बजाय trend देखें।

• Flaky rate — टेस्ट रनों का वह हिस्सा जो fail होकर retry में pass हुआ, या कोड बदलाव के बिना fail हुआ।
• Top offenders — वे चंद टेस्ट जो ज़्यादातर flaky failures के ज़िम्मेदार हैं; इन्हें ठीक करने से आमतौर पर सबसे बड़ा सुधार मिलता है।
• Time to fix — कोई टेस्ट कितने समय तक flagged या quarantined रहता है।
• Rerun cost — retries और manual reruns पर ख़र्च हुए pipeline minutes और person-hours।

टेस्ट लिखते समय flakiness रोकना

• कोई fixed sleep नहीं; हर wait timeout वाली एक condition है।
• यूज़र को दिखने वाले नतीजों पर retry करने वाले assertions, एक बार पढ़ने वाले नहीं।
• Role, label, text या test ids पर आधारित मज़बूत locators — locator रणनीतियों वाली गाइड देखें।
• हर टेस्ट अपना डेटा बनाता है और उसका मालिक है, हर रन और हर worker के लिए unique values के साथ।
• State API से set up होती है, असंबंधित screens पर क्लिक करके नहीं।
• Third-party services stub की जाती हैं; जहाँ तारीख़ें मायने रखती हैं वहाँ clock और time zone कंट्रोल होते हैं।
• नए टेस्ट blocking suite में जुड़ने से पहले कई बार चलाए जाते हैं — उदाहरण के लिए 20 से 50 बार।
• Suite parallel में चलता है और समय-समय पर random order में, ताकि छिपी निर्भरताएँ जल्दी सामने आएँ।

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

संदर्भ

• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
• Trace viewer — PlaywrightMicrosoft (Playwright)टेस्ट रन को क़दम-दर-क़दम रिकॉर्ड और रीप्ले करना — DOM स्नैपशॉट, नेटवर्क, कंसोल — ख़ासकर CI की विफलताओं का निदान करने के लिए।
• Auto-waiting — PlaywrightMicrosoft (Playwright)हर एक्शन से पहले Playwright की actionability जाँचें — visible, stable, enabled, events प्राप्त करने योग्य — जो ज़्यादातर हाथ से लिखे wait की ज़रूरत हटाती हैं।
• Waiting Strategies — SeleniumSelenium Projectब्राउज़र टेस्ट पेज से race क्यों करते हैं, और implicit व explicit waits WebDriver स्क्रिप्ट को ऐप के साथ कैसे सिंक करते हैं।
• Best Practices — CypressCypress.ioसमर्पित एट्रिब्यूट से एलिमेंट चुनने, फ़िक्स्ड wait से बचने और टेस्ट को स्वतंत्र रखने पर Cypress की गाइडेंस।
• Best Practices — PlaywrightMicrosoft (Playwright)यूज़र को दिखने वाला व्यवहार टेस्ट करें, टेस्ट अलग-थलग रखें, मज़बूत locator और web-first assertions अपनाएँ, और trace से डिबग करें।