Odpowiedź.

Automatyzacja testowania kodu legacy to jeden z największych klasycznych problemów w dziedzinie IT.

Historia zagadnienia: Wiele firm zmaga się z koniecznością testowania systemów, które były pisane bez uwzględnienia przyszłej automatyzacji. Często takie projekty posiadają słabą dokumentację, wysoki dług techniczny oraz brak izolowanych komponentów.

Problem: Główne trudności pojawiają się z powodu

braku haków testowych i punktów integracji
niemożności izolacji danych do testowania
silnej wzajemnej zależności modułów
dużej liczby anomalii i zmian, które nie są odzwierciedlone w kodzie

Rozwiązanie: Zwykle proces przebiega krok po kroku:

Analiza systemu: konieczne jest określenie krytycznych procesów biznesowych i ustalenie obszaru pokrycia testami automatycznymi.
Wprowadzenie punktów testowych: w miarę możliwości część kodu obwrapowuje się proxy, dostosowuje do testowych duplikatów lub stosuje wzorzec dependency injection.
Krokowe pokrycie testami automatycznymi: najpierw pisane są testy dla "najprostszych" i najmniej powiązanych fragmentów kodu.
Stałe wsparcie i refaktoryzacja: po dodaniu testów wykorzystuje się je jako siatkę zabezpieczającą dla usprawnień.

Kluczowe cechy:

Testy często zaczynają pisać nie od zera, ale od "owijek" nad istniejącymi funkcjami.
Konieczne jest etapowe wprowadzanie testowalności w architekturę.
Biznes powinien być maksymalnie zaangażowany w regulację krytycznych scenariuszy.

Pytania z podwójnym dnem.

Czy można zacząć pisać testy automatyczne przed całkowitą refaktoryzacją kodu legacy?

Tak, często testy automatyczne są potrzebne, aby zabezpieczyć proces refaktoryzacji. Nie można czekać na pełną "doskonałość" — wręcz przeciwnie, testy pomagają zmieniać się odważnie.

Czy warto od razu próbować pokryć cały kod legacy testami automatycznymi?

Nie. Należy skupić się na najbardziej ryzykownych i często używanych scenariuszach. Pokrycie "wszystkiego na raz" szkodzi prędkości i nie ma sensu.

Czy konieczne jest wprowadzanie nowoczesnych wzorców, takich jak DI, aby testować kod legacy?

Nie, ale zaleca się ich stosowanie, jeśli pozwalają na to zasoby. Pierwszym krokiem jest przynajmniej częściowa izolacja, mocki oraz specjalne punkty testowe w kodzie.

Typowe błędy i antywzorce

Migracja całego kodu od razu pod testy automatyczne — projekty zatrzymują się i tracą sens biznesowy.
"Paranoidalne" pokrycie nieistotnych funkcji.
Brak komunikacji między rozwojem, testowaniem a biznesem.

Przykład z życia

Negatywny przypadek

Zespół próbował wprowadzać testy automatyczne, przepisując całą starą aplikację według wzorców SOLID i obejmując testami 100% kodu.

Plusy:

Podstawowa poprawa architektury.
W dłuższej perspektywie testy mogą przynieść korzyści.

Minusy:

Wstrzymanie rozwoju na kilka miesięcy.
Ciągłe błędy i rozbieżności z wymaganiami biznesowymi.
Utrata aktualności kodu w momencie, gdy testy zostaną napisane.

Pozytywny przypadek

Wprowadzano testy automatyczne tylko dla kluczowych punktów obliczeniowych wraz z wprowadzeniem specjalnych stabilizatorów, minimalnie zmieniając ogólny kod.