Test coverage क्या है?

Question

Accepted Answer

**Test coverage** मापता है कि code का कितना हिस्सा **tests द्वारा निष्पादित** होता है — आमतौर पर एक प्रतिशत के रूप में (जैसे 80% coverage)। यह बिना परीक्षित code खोजने के लिए एक उपयोगी metric है, लेकिन इसकी सीमाओं को समझना महत्वपूर्ण है: उच्च coverage अच्छे tests की गारंटी नहीं देता।

## Coverage क्या मापता है

```text
TEST COVERAGE = the % of code exercised by the test suite:
  LINE coverage → % of code lines executed by tests
  BRANCH coverage → % of branches (if/else paths) taken
  FUNCTION coverage → % of functions called
  STATEMENT coverage → % of statements executed
→ Coverage tools instrument the code and report what tests do/don't exercise.
```

## Coverage क्यों उपयोगी है

```text
✓ FINDS UNTESTED code — low coverage areas reveal what lacks tests (a gap finder)
✓ A measurable quality signal; track it over time; many teams set a target (e.g. ≥80%)
✓ Highlights branches/paths/error cases that tests miss
```

## सीमाएँ (महत्वपूर्ण!)

```text
⚠️ HIGH COVERAGE ≠ GOOD TESTS:
  → coverage shows code was EXECUTED, NOT that behavior was correctly VERIFIED
  → you can execute code with NO meaningful assertions → 100% coverage, tests verify nothing
  → 100% coverage can still miss bugs (untested input combinations, logic errors)
⚠️ Chasing a coverage NUMBER → writing low-value tests just to hit the target
→ Coverage is a USEFUL guide (find gaps), NOT a guarantee of quality. Use it wisely;
  focus on testing important behavior well, not just hitting a percentage.
```

## यह क्यों महत्वपूर्ण है

Test coverage को समझना — इसकी सीमाओं सहित — मूल्यवान है क्योंकि यह एक **सामान्य रूप से उपयोग किया जाने वाला metric** है जो सही ढंग से समझे जाने पर उपयोगी है लेकिन गलत उपयोग किए जाने पर भ्रामक है, इसलिए यह महत्वपूर्ण व्यावहारिक ज्ञान है।

Coverage मापता है कि **tests द्वारा कितना code निष्पादित होता है** (एक प्रतिशत के रूप में, line, branch, function, या statement coverage के माध्यम से), और इसे समझना उपयोगी है क्योंकि यह **बिना परीक्षित code खोजता है** (उन अंतरालों को प्रकट करता है जहाँ tests की कमी है — यह पहचानने का एक मूल्यवान तरीका कि क्या परीक्षण की आवश्यकता है), एक मापने योग्य गुणवत्ता संकेत प्रदान करता है जिसे teams ट्रैक कर सकती हैं, और चूके हुए branches और error cases को उजागर करता है।

कई teams coverage को targets के साथ एक गुणवत्ता metric के रूप में उपयोग करती हैं।

हालाँकि, **सीमाओं को समझना अत्यंत महत्वपूर्ण है**: **उच्च coverage अच्छे tests के बराबर नहीं है** — coverage दिखाता है कि code *निष्पादित* हुआ, यह नहीं कि उसका व्यवहार सही ढंग से *सत्यापित* हुआ, इसलिए आपके पास अर्थहीन tests के साथ उच्च (यहाँ तक कि 100%) coverage हो सकती है (उचित assertions के बिना code निष्पादित करना कुछ भी सत्यापित नहीं करता), और पूर्ण coverage अभी भी bugs को चूक सकती है (बिना परीक्षित input संयोजन, logic errors)।

एक **coverage संख्या का पीछा करने** का खतरा (एक target तक पहुँचने के लिए केवल कम-मूल्य वाले tests लिखना) एक वास्तविक anti-pattern है।

यह समझना कि **coverage अंतराल खोजने के लिए एक उपयोगी मार्गदर्शक है, गुणवत्ता की गारंटी नहीं** — और कि ध्यान एक प्रतिशत तक पहुँचने के बजाय महत्वपूर्ण व्यवहार को अच्छी तरह परीक्षण करने पर होना चाहिए — परिपक्व विवेक को दर्शाता है जो coverage को एक उपकरण के बजाय लक्ष्य मानने की सामान्य गलती से बचता है।

चूँकि coverage एक व्यापक रूप से उपयोग किया जाने वाला metric है जो वास्तव में उपयोगी है (बिना परीक्षित code खोजना) लेकिन सामान्य रूप से गलत समझा और गलत उपयोग किया जाता है (एक गुणवत्ता गारंटी या game करने के लिए एक target के रूप में माना जाता है), और चूँकि इसके मूल्य और इसकी महत्वपूर्ण सीमाओं दोनों को समझना इसे बुद्धिमानी से उपयोग करने में सक्षम बनाता है, test coverage को समझना मूल्यवान, व्यावहारिक रूप से प्रासंगिक ज्ञान है — एक उपयोगी metric जिसे सही ढंग से समझना चाहिए, जहाँ इसकी सीमाओं की सराहना करना (coverage ≠ गुणवत्ता) metric स्वयं जितना ही महत्वपूर्ण है, ठोस testing विवेक को दर्शाता है।