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

Po co się tego uczymy?

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ę SAME, przy każdej zmianie kodu — bez polegania na ludzkiej pamięci. To ostatni element wymagania INF.04.8.3.

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

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)         │

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

.github/workflows/testy.yml (GitHub Actions)

# .github/workflows/testy.yml
# Przykładowa konfiguracja GitHub Actions - uruchamia testy
# automatycznie przy każdym "push" do repozytorium.

name: Uruchom testy

on: [push]

jobs:
  testy-backend:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Instalacja .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - name: Przywróć zależności
        run: dotnet restore
      - name: Uruchom testy backendu (xUnit/MSTest)
        run: dotnet test

  testy-frontend:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Instalacja Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Instalacja zależności
        run: npm install
      - name: Uruchom testy frontendu (Jasmine/Karma)
        run: npm test -- --watch=false --browsers=ChromeHeadless

Komentarz i wyjaśnienie kodu

on: [push] określa, KIEDY workflow ma się uruchomić — tutaj przy KAŻDYM wysłaniu zmiany do repozytorium (niezależnie od gałęzi). Można też skonfigurować uruchamianie tylko dla konkretnej gałęzi albo dla "pull requestów" (propozycji zmian przed ich scaleniem).

Dwa niezależne zadania (testy-backend i testy-frontend) odzwierciedlają DWUWARSTWOWĄ architekturę aplikacji webowej z lekcji 5 — backend testowany dotnet test (xUnit/MSTest), frontend npm test (Jasmine/Karma). Oba zadania uruchamiają się RÓWNOLEGLE, więc łączny czas oczekiwania na wynik jest krótszy niż suma obu.

--browsers=ChromeHeadless oznacza uruchomienie testów Angulara w przeglądarce Chrome BEZ interfejsu graficznego (headless) — niezbędne, bo serwer CI nie ma monitora ani środowiska graficznego, na którym mogłaby wyświetlić się zwykła przeglądarka.

Ćwiczenie samodzielne

Uruchom lokalnie dotnet test dla dowolnego z projektów testowych stworzonych w lekcjach 2-5 (albo ng test dla projektu Angular) i sprawdź wynik w terminalu — porównaj to z klikaniem pojedynczych testów w Eksploratorze testów Visual Studio.

Zadania do pracy własnej

Wypisz, jakie korzyści (co najmniej 3) daje uruchamianie testów automatycznie przy każdej zmianie kodu (CI) w porównaniu do ręcznego uruchamiania ich "od czasu do czasu" przez programistę.
Zaprojektuj (opisz słownie, bez pisania prawdziwego YAML) kroki, jakie powinien wykonać serwer CI dla projektu .NET MAUI: co należy zainstalować, skompilować i przetestować, zanim aplikacja trafi do dalszych etapów (np. publikacji w sklepie, lekcja 26 działu MAUI).
Rozbuduj przykładowy plik testy.yml o trzeci, sekwencyjny krok, który uruchamia się TYLKO wtedy, gdy oba poprzednie zadania (testy-backend i testy-frontend) zakończyły się sukcesem — krok symbolicznie reprezentujący "wdrożenie na środowisko testowe" (patrz lekcja 7). Wyjaśnij, jakiej właściwości/atrybutu GitHub Actions użyłbyś, żeby wymusić tę zależność między zadaniami.

Typowe błędy

Traktowanie automatyzacji testów jako zastępstwa dla PISANIA testów — CI automatyzuje URUCHAMIANIE istniejących testów, ale nie tworzy ich za programistę; bez dobrych testów jednostkowych/integracyjnych automatyzacja nie ma czego uruchamiać.

Ignorowanie "czerwonego" wyniku CI ("zaraz to poprawię, na razie pracuję dalej") — pozwolenie, żeby zespół przyzwyczaił się do failującego builda, niweczy sens całej automatyzacji: jeśli czerwony wynik jest "normalny", nikt już nie zwraca na niego uwagi, gdy pojawi się PRAWDZIWY, nowy problem.

Automatyzowanie WOLNYCH testów end-to-end zamiast szybkich testów jednostkowych — jeśli CI trwa 40 minut, bo głównie uruchamia testy klikające całą aplikację w przeglądarce, programiści przestają czekać na wynik i zaczynają go ignorować. Piramida testów (więcej jednostkowych, mniej end-to-end) utrzymuje CI szybkim i użytecznym.

Nawiązanie do egzaminu zawodowego

To domknięcie INF.04.8.3 w części o automatyzacji testów. Razem z poprzednimi lekcjami (testy jednostkowe w 4 kontekstach, testy niefunkcjonalne, organizacja procesu, dokumentacja) dział pokrywa całościowo INF.04.8. W ostatniej lekcji tego działu połączysz WSZYSTKIE poznane elementy w jednym zadaniu kontrolnym — napiszesz klasę z logiką biznesową i kompletny zestaw testów jednostkowych.