फ्लेकी परीक्षणहरू के हुन् र तपाई कसरी तिनलाई सम्हाल्नु हुन्छ?

Question

Accepted Answer

**फ्लेकी परीक्षणहरू** परीक्षणहरू हुन् जो **अचम्मको रूपमा पास वा असफल हुन्छन्** कोडमा कुनै परिवर्तन बिना — कहिले पास हुन्छ, कहिले एकै कोडमा असफल हुन्छ। यो एक गम्भीर समस्या हो किनभने यो परीक्षण सूटमा विश्वास कमजोर गर्छ। तिनीहरूका कारणहरू र समाधानहरू बुझ्न महत्त्वपूर्ण छ।

## फ्लेकी परीक्षणहरू के हुन् र किन हानिकारक छन्

```text
A FLAKY test gives INCONSISTENT results (pass sometimes, fail other times) on the SAME code:
  → harmful: ERODES TRUST — people start ignoring failures ("oh, it's just flaky") →
    real failures get missed too
  → waste time on false alarms / re-runs; break CI; reduce confidence in the whole suite
→ Flaky tests are worse than no test if they make people distrust all tests.
```

## सामान्य कारणहरू

```text
✗ TIMING / async → race conditions; not waiting properly for async operations (a top cause
  in UI/E2E tests); arbitrary sleeps
✗ ORDER DEPENDENCE → tests depending on each other / shared mutable state
✗ EXTERNAL dependencies → real network/services (network blips, rate limits, downtime)
✗ NON-DETERMINISM → time/dates, randomness, timezone, locale
✗ Test ENVIRONMENT → leftover state, uncleaned data, concurrency/parallelism issues
```

## फ्लेकी परीक्षणहरू ठीक गर्ने र प्रबन्ध गर्ने

```text
✓ Fix the ROOT CAUSE: wait for conditions (not sleeps); make tests INDEPENDENT and clean
  up state; MOCK external dependencies; control time/randomness (inject them)
✓ Ensure proper isolation (no shared state, no order dependence)
✓ Don't just RETRY blindly (it hides the problem) — investigate and fix
✓ QUARANTINE persistently flaky tests (isolate so they don't block) WHILE fixing them
✓ Treat flakiness seriously — track and address it (it degrades the whole suite)
```

## यो किन महत्त्वपूर्ण छ

फ्लेकी परीक्षणहरू बुझ्न र तिनलाई कसरी सम्हाल्ने भनेर बुझ्न महत्त्वपूर्ण छ किनभने **फ्लेकी परीक्षणहरू एक गम्भीर, सामान्य समस्या हुन् जसले सम्पूर्ण परीक्षण सूटको मूल्य कमजोर गर्छ**, त्यसैले यो मूल्यवान व्यावहारिक ज्ञान हो।

एक फ्लेकी परीक्षण (एकै कोडमा अचम्मको रूपमा पास वा असफल हुने) विशेष गरी हानिकारक छ किनभने यो **विश्वास कमजोर गर्छ**: जब परीक्षणहरू अप्रत्याशित रूपमा असफल हुन्छन्, मानिसहरूले असफलताहरू उपेक्षा गर्न सुरु गर्छन् ("यो सिर्फ फ्लेकी छ"), जसको अर्थ **वास्तविक असफलताहरू पनि छोडिन्छन्** — त्यसैले फ्लेकिनेसले सम्पूर्ण सूटमा आत्मविश्वास खराब गर्छ, सम्भवतः यसलाई उपयोगी भन्दा खराब बनाउँछ।

यो हानि बुझ्नले फ्लेकिनेसलाई गम्भीरताले लिन प्रेरित गर्छ।

**सामान्य कारणहरू** बुझ्न — **समय/async समस्याहरू** (race conditions, async अपरेशनका लागि सही ढङ्गले प्रतीक्षा नगरी, मनमानी sleeps — विशेष गरी UI/E2E परीक्षणहरूमा एक शीर्ष कारण), **क्रम निर्भरता** (परीक्षणहरू एक अर्कामा निर्भर वा साझा अवस्थामा), **बाहिरी निर्भरताहरू** (वास्तविक नेटवर्क/सेवाहरू तिनीहरूका समस्याहरू र डाउनटाइमसँग), **अनिर्धारकता** (समय, अनियमितता, समय क्षेत्र, स्थान), र **वातावरण समस्याहरू** (बाकी अवस्था, समवर्तिता) — आवश्यक छ।

फ्लेकिनेसलाई **ठीक गर्ने र प्रबन्ध गर्ने** तरिका बुझ्न — मूल कारणहरू ठीक गर्ने (sleeps को सट्टा अवस्थाहरूको लागि प्रतीक्षा गर्ने, परीक्षणहरूलाई स्वतन्त्र र स्वच्छ बनाउने, बाहिरी निर्भरताहरूलाई मक गर्ने, समय र अनियमितता नियन्त्रण गर्ने), अलगीकरण सुनिश्चित गर्ने, **अन्धाधुन्द रूपमा पुनः प्रयास नगरी** (जसले समस्याहरू लुकाउँछ), लगातार फ्लेकी परीक्षणहरूलाई अलग राख्दै तिनीहरू ठीक गर्दा, र फ्लेकिनेसलाई एक गम्भीर समस्या मानेर ट्र्याक र समाधान गर्ने — सही दृष्टिकोण प्रतिबिम्बित गर्छ।

फ्लेकी परीक्षणहरू एक सामान्य, गम्भीर समस्या हुन् जसले परीक्षण सूटमा विश्वास र मूल्य कमजोर गर्छ (धेरै वास्तविक-विश्व परियोजनाहरूमा एक वास्तविक समस्या), र चूँकि तिनीहरूका कारणहरू र उचित ह्यान्डलिङ (मूल कारणहरू ठीक गर्ने, अलगीकरण, सिर्फ पुनः प्रयास गरी होइन) बुझ्न आवश्यक छ एक विश्वसनीय परीक्षण सूट कायम राख्नको लागि, फ्लेकी परीक्षणहरू बुझ्न मूल्यवान, व्यावहारिक महत्त्वपूर्ण ज्ञान हो — एक महत्त्वपूर्ण वास्तविक-विश्व परीक्षण समस्या समाधान गर्दै, परीक्षण सूटलाई विश्वसनीय र विश्वस्त राख्नको लागि महत्त्वपूर्ण, र परीक्षणको सबैभन्दा निराशाजनक र क्षतिकारक समस्याहरूमा एक गर्न सक्षम हुनको व्यावहारिक परिपक्कता प्रतिबिम्बित गर्दै।