Średni · lekcja 9

Automatyzacja testów — od uruchomienia ręcznego do CI

Napisanie testów (lekcje 2-5) to dopiero połowa sukcesu — jeśli ktoś musi PAMIĘTAĆ, żeby je ręcznie uruchomić przed każdą zmianą, prędzej czy później ktoś o tym zapomni i błąd "przecieknie" dalej. Automatyzacja testów to sprawienie, żeby testy uruchamiały się...

Zacznij tutaj

Po co się tego uczymy?

Wprowadzenie

Teoria

Od testu manualnego do automatycznego — przypomnienie. Test MANUALNY wymaga człowieka, który klika i ręcznie sprawdza wynik za każdym razem od nowa. Test AUTOMATYCZNY (jak te pisane w MSTest/xUnit/Jasmine w lekcjach 2-5) to KOD, który sam sprawdza inny kod — może być uruchomiony dowolną liczbę razy, zawsze tak samo, bez zmęczenia czy pomyłki człowieka.

Uruchamianie testów lokalnie — pierwszy poziom automatyzacji. Zamiast klikać pojedynczo każdy test w Visual Studio, można uruchomić WSZYSTKIE testy jedną komendą: dotnet test (dla projektów .NET — MSTest/xUnit) albo ng test (dla Angulara — Jasmine/Karma). To już automatyzacja, choć nadal wymaga, żeby KTOŚ pamiętał, żeby tę komendę uruchomić.

CI — Continuous Integration (integracja ciągła). To praktyka polegająca na tym, że za KAŻDYM razem, gdy programista wysyła zmianę kodu do wspólnego repozytorium (np. przez git push), SERWER automatycznie: pobiera najnowszy kod, kompiluje go, i uruchamia WSZYSTKIE testy — bez udziału człowieka. Jeśli którykolwiek test padnie, cały zespół natychmiast widzi czerwony status ("build failed") i wie, że coś jest nie tak, ZANIM zepsuty kod trafi dalej.

Dlaczego CI zmienia jakość pracy zespołu — bez CI błąd może zostać wykryty dopiero po dniach czy tygodniach (gdy ktoś przypadkiem na niego trafi), co utrudnia znalezienie PRZYCZYNY (który z wielu commitów ją wprowadził?). Z CI błąd wykrywany jest w ciągu minut od wprowadzenia zmiany — łatwo wskazać dokładnie, KTÓRA zmiana go spowodowała.

Popularne narzędzia CI — GitHub Actions (zintegrowane z GitHub, konfiguracja przez plik YAML w repozytorium), GitLab CI, Azure DevOps Pipelines, Jenkins. Wszystkie działają na podobnej zasadzie: definiujesz "co ma się wydarzyć" (np. "uruchom dotnet test") w pliku konfiguracyjnym, a serwer CI robi to automatycznie przy każdej zmianie.

Piramida automatyzacji w praktyce — najwięcej zautomatyzowanych powinno być testów jednostkowych (szybkie, tanie w utrzymaniu), mniej testów integracyjnych, jeszcze mniej pełnych testów funkcjonalnych typu "end-to-end" (symulujących całą ścieżkę użytkownika w przeglądarce — wolne i kosztowne w utrzymaniu, bo łatwo się psują przy zmianach interfejsu).

Zobacz zależności

Schemat

AUTOMATYZACJA TESTÓW — proces CI

Programista            Repozytorium (GitHub)        Serwer CI
     │                        │                          │
     │──── git push ─────────▶│                          │
     │                        │──── wyzwala automatycznie▶│
     │                        │                          │
     │                        │      1. Pobierz kod       │
     │                        │      2. Skompiluj          │
     │                        │      3. dotnet test        │
     │                        │      4. ng test             │
     │                        │                          │
     │◄── wynik: ✔ zielony lub ✘ czerwony (build failed) ──│
     │  (widoczny dla całego zespołu w ciągu minut)         │

Połącz z praktyką

Przykład z życia

Fabryka samochodów ma automatyczne linie kontroli jakości — każdy element (drzwi, silnik, hamulce) jest sprawdzany maszynowo na każdym etapie produkcji, a nie dopiero na końcu przez jednego człowieka oglądającego gotowe auto. Dzięki temu wadliwy element wykrywany jest NATYCHMIAST, blisko miejsca, gdzie powstał, zanim trafi do kolejnych etapów montażu. CI działa dokładnie na tej samej zasadzie w świecie oprogramowania — automatyczna kontrola jakości przy KAŻDEJ zmianie, a nie tylko "na końcu".