Mi az a tesztelési lefedettség?

Question

Accepted Answer

**A tesztelési lefedettség** azt méri, hogy a kód mekkora része fut le tesztek által — jellemzően százalékban kifejezve (pl. 80% lefedettség). Hasznos metrika az untestelt kód megtalálásához, de fontos megérteni a korlátait: a magas lefedettség nem garantálja a jó teszteket.

## Mit mér a lefedettség

```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.
```

## Miért hasznos a lefedettség

```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
```

## A korlátok (fontos!)

```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.
```

## Miért számít

A tesztelési lefedettség megértése — beleértve annak korlátait is — értékes, mivel ez egy **gyakran használt metrika**, amely helyesen értelmezve hasznos, de félreértelmezve félrevezető, ezért fontos gyakorlati tudás.

A lefedettség azt méri, hogy **mekkora része fut le a kódnak a tesztek által** (százalékban, sor, branch, függvény vagy utasítás lefedettségen keresztül), és megértése hasznos, mivel **felleméri az untestelt kódot** (feltárja azokat a hiányosságokat, ahol tesztek hiányoznak — értékes módja annak, hogy azonosítsuk, mit kell tesztelni), mérhető minőségi jelet nyújt, amelyet a csapatok nyomon követhetnek, és kiemeli az elmaradt ágakat és hibakezelési eseteket.

Nagy sok csapat a lefedettséget minőségi metrikként használja célokkal.

Az **korlátok megértése azonban kritikusan fontos**: **a magas lefedettség nem jelent jó teszteket** — a lefedettség azt mutatja, hogy a kód *végrehajtódott*, nem azt, hogy a viselkedése helyesen *ellenőriztetett*, így lehet magas (akár 100%-os) lefedettségünk értelmetlen tesztekkel (a kód végrehajtása megfelelő assertiók nélkül nem igazol semmit), és a teljes lefedettség még mindig kihagyhat hibákat (untestelt bemeneti kombinációk, logikai hibák).

A **lefedettségi szám hajszálása** (alacsony értékű tesztek írása csak a cél eléréséhez) valódi anti-pattern.

Annak megértése, hogy a **lefedettség hasznos iránymutatás a hiányosságok megtalálásához, nem a minőség garanciája** — és hogy a hangsúly a fontos viselkedés jó tesztelésén kell lennie, nem pedig egy százalék elérésén — érett ítéletet tükröz, amely elkerüli a gyakori hibát, amikor a lefedettséget célnak tekintik ahelyett, hogy eszköznek.

Mivel a lefedettség széles körben használt metrika, amely valóban hasznos (untestelt kód megtalálása), de gyakran félreértett és visszaélésekkel él (minőség garanciájaként vagy játszható célként kezelik), és mivel megérteni mind az értékét, mind az annak fontos korlátait lehetővé teszi a bölcs felhasználást, a tesztelési lefedettség megértése értékes, gyakorlati releváns tudás — egy hasznos metrika, amelyet helyesen kell megérteni, ahol annak korlátainak (lefedettség ≠ minőség) megértése ugyanolyan fontos, mint a metrika maga, ami szilárd tesztelési ítéletet tükröz.