Jak dodajesz testy do kodu legacy?

Question

Accepted Answer

**Kod legacy** (często nietestowany, trudny do modyfikacji kod) jest trudny do testowania — może mieć splątane zależności i brak testów. Dodawanie testów bezpiecznie obejmuje techniki takie jak **testy charakteryzacyjne**, **seamy** do przerwania zależności i inkrementalne ulepszanie, umożliwiające bezpieczniejsze zmiany.

## Problem kodu legacy

```text
Legacy code is often: untested, tightly coupled, hard to understand, risky to change:
  → no tests → changing it is dangerous (you can't tell if you broke something)
  → hard to test → dependencies are tangled (can't isolate units); not designed for testing
→ a chicken-and-egg problem: to change safely you need tests, but it's hard to test.
```

## Testy charakteryzacyjne (ustalenie bieżącego zachowania)

```text
CHARACTERIZATION (golden master) tests → capture the code's CURRENT behavior as-is
  (even if you don't fully understand it / it has bugs):
  → write tests asserting what it ACTUALLY does now → a SAFETY NET
  → then you can refactor/change with confidence that behavior is preserved
→ Don't assert what it SHOULD do — assert what it DOES, to protect against regressions.
```

## Przerwanie zależności (seamy)

```text
To isolate hard-to-test code, find/create SEAMS (places to substitute dependencies):
  → extract dependencies behind interfaces; inject them; use the smallest safe refactors
    to make code testable (Michael Feathers' techniques)
  → carefully break dependencies so you can get the code under test, then test, then refactor
```

## Podejście inkrementalne

```text
✓ Add tests AROUND code BEFORE changing it (a safety net for the change)
✓ Focus on areas you're CHANGING / high-risk / high-value (not the whole codebase at once)
✓ Improve incrementally — leave code a bit better each time (the "boy scout rule")
✓ Use characterization tests to capture behavior, then refactor toward testability
```

## Dlaczego to ważne

Zrozumienie, jak dodawać testy do kodu legacy, jest cenną wiedzą na poziomie senior, ponieważ **większość pracy w świecie rzeczywistym obejmuje istniejący, często nietestowany kod**, a jego bezpieczne ulepszanie jest powszechnym i ważnym wyzwaniem, dlatego jest praktycznie istotne.

Kod legacy (nietestowany, ściśle powiązany, trudny do zmiany) stoi przed rzeczywistym **problemem koła jajka i kury**: aby zmienić go bezpiecznie, potrzebujesz testów, ale trudno go testować (splątane zależności, nie został zaprojektowany do testowania) — a zmiana nietestowanego kodu jest niebezpieczna, ponieważ nie możesz powiedzieć, czy coś złamałeś.

Zrozumienie technik rozwiązania tego problemu jest cenną praktyczną wiedzą. **Testy charakteryzacyjne** (uchwycenie *bieżącego* zachowania kodu takim, jakie jest, asertowanie tego, co faktycznie robi, a nie tego, co powinno — nawet jeśli nie jest w pełni zrozumiane) stanowią **sieć bezpieczeństwa**, która pozwala na refaktoryzację i zmianę z pewnością, że istniejące zachowanie jest zachowane — kluczowa technika pracy z kodem, którego nie w pełni rozumiesz.

Zrozumienie **przerwania zależności poprzez seamy** (znalezienie lub utworzenie miejsc do zastąpienia zależności, używając minimalnych bezpiecznych refaktoryzacji w celu uczynienia splątanego kodu testowalnym — techniki z pracy Michaela Feathersa nad kodem legacy) jest niezbędne do poddania trudnego do testowania kodu testom.

Zrozumienie **podejścia inkrementalnego** — dodawanie testów wokół kodu przed jego zmianą (sieć bezpieczeństwa dla zmiany), skupienie się na obszarach, które są zmieniane lub wysokiego ryzyka/wysokiej wartości (nie całej bazy kodu na raz) i inkrementalne ulepszanie (reguła skautów) — odzwierciedla pragmaticzny, realistyczny sposób ulepszania systemów legacy w miarę upływu czasu.

Ponieważ większość pracy w świecie rzeczywistym obejmuje istniejący, często nietestowany kod legacy, który musi być zmieniony bezpiecznie (powszechna, trudna sytuacja), a ponieważ zrozumienie technik (testy charakteryzacyjne dla sieci bezpieczeństwa, seamy do przerwania zależności, inkrementalne ulepszanie) umożliwia to robienie, zrozumienie, jak dodawać testy do kodu legacy, jest cenną wiedzą na poziomie senior — praktycznie istotne dla powszechnej rzeczywistości pracy z istniejącym nietestowanym kodem, odzwierciedlające doświadczenie i techniki potrzebne do bezpiecznego ulepszania systemów legacy, ważna kompetencja dla inżynierów senior, którzy często muszą uczynić nietestowany kod bezpieczniejszym do modyfikacji.