Co to jest pokrycie testami?

Question

Accepted Answer

**Pokrycie testami** mierzy, jak dużą część kodu **wykonują testy** — zwykle wyrażane jako procent (np. 80% pokrycia). Jest to przydatna miara do znajdowania nieprzetestowanego kodu, ale ważne jest zrozumienie jej ograniczeń: wysokie pokrycie nie gwarantuje dobrych testów.

## Co mierzy pokrycie

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

## Dlaczego pokrycie jest przydatne

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

## Ograniczenia (ważne!)

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

## Dlaczego to ważne

Zrozumienie pokrycia testami — w tym jego ograniczeń — jest cenne, ponieważ jest to **powszechnie stosowana miara**, która jest przydatna, gdy jest rozumiana prawidłowo, ale może być myląca, gdy jest nadużywana, dlatego stanowi ważną wiedzę praktyczną.

Pokrycie mierzy **jak dużą część kodu wykonują testy** (jako procent, poprzez pokrycie linii, rozgałęzień, funkcji lub instrukcji), a jego zrozumienie jest przydatne, ponieważ **znajduje nieprzetestowany kod** (ujawniając luki, gdzie brakuje testów — cenny sposób na zidentyfikowanie tego, co wymaga testowania), zapewnia mierzalny sygnał jakości, którym zespoły mogą się kierować, i podkreśla pominięte rozgałęzienia i przypadki błędów.

Wiele zespołów używa pokrycia jako metryki jakości z określonymi celami.

Jednak zrozumienie **ograniczeń jest krytycznie ważne**: **wysokie pokrycie nie równa się dobrym testom** — pokrycie pokazuje, że kod był *wykonany*, a nie że jego zachowanie zostało prawidłowo *zweryfikowane*, dlatego możesz mieć wysokie (nawet 100%) pokrycie z bezwartościowymi testami (wykonanie kodu bez odpowiednich asercji nic nie weryfikuje), a pełne pokrycie może nadal nie wykryć błędów (nieprzetestowane kombinacje danych wejściowych, błędy logiki).

Niebezpieczeństwo **dążenia do określonego procentu pokrycia** (pisanie testów o niskiej wartości tylko po to, aby osiągnąć cel) to rzeczywisty anty-wzorzec.

Zrozumienie, że **pokrycie jest użytecznym przewodnikiem do znajdowania luk, a nie gwarancją jakości** — i że fokus powinien być na dobrym testowaniu ważnego zachowania raczej niż na osiągnięciu procenta — odzwierciedla dojrzały osąd, który unika powszechnego błędu traktowania pokrycia jako celu zamiast narzędzia.

Ponieważ pokrycie jest powszechnie stosowaną metryką, która jest naprawdę przydatna (znajdowanie nieprzetestowanego kodu), ale powszechnie niezrozumiana i nadużywana (traktowana jako gwarancja jakości lub cel do osiągnięcia), a zrozumienie zarówno jej wartości, jak i ważnych ograniczeń pozwala na mądre jej stosowanie, zrozumienie pokrycia testami jest cenną, praktycznie istotną wiedzą — przydatną metryką do prawidłowego zrozumienia, gdzie docenianie jej ograniczeń (pokrycie ≠ jakość) jest tak samo ważne, jak sama miara, odzwierciedlając solidny osąd w testowaniu.