Wprowadzenie do testowania — rodzaje testów i metodyki

Po co się tego uczymy?

Napisany kod, który "wygląda na działający", to nie to samo co kod SPRAWDZONY. Testowanie to systematyczny sposób udowodnienia (sobie i innym), że program robi to, co powinien — również w sytuacjach nietypowych. To wymaganie egzaminacyjne wprost (INF.04.8: "przeprowadza walidację kodu programu", "przeprowadza testy") i temat, który realnie pojawiał się na egzaminie INF.04 w poprzednich latach.

Teoria

Dlaczego testujemy? Im większy program, tym trudniej ręcznie sprawdzić wszystkie możliwe ścieżki działania. Testy automatyczne pozwalają: (1) szybko wykryć błąd ZANIM trafi do użytkownika, (2) bezpiecznie zmieniać kod — jeśli coś zepsujesz, testy "krzykną" czerwonym kolorem, (3) mieć DOKUMENTACJĘ tego, jak kod powinien się zachowywać (test to precyzyjny przykład użycia).

Piramida testów — cztery główne rodzaje:

Testy jednostkowe (unit tests) — sprawdzają NAJMNIEJSZĄ możliwą jednostkę kodu, zwykle pojedynczą metodę, w IZOLACJI od reszty systemu (bez bazy danych, bez sieci, bez interfejsu). Szybkie (tysiące w ciągu sekund), liczne, pierwsza linia obrony.
Testy integracyjne — sprawdzają, czy KILKA elementów współpracuje poprawnie ZE SOBĄ (np. czy serwis rzeczywiście poprawnie zapisuje dane do prawdziwej bazy danych). Wolniejsze niż jednostkowe, mniej liczne.
Testy funkcjonalne — sprawdzają, czy cała FUNKCJONALNOŚĆ (widziana oczami użytkownika) działa zgodnie z wymaganiami, np. "czy da się złożyć zamówienie od A do Z".
Testy niefunkcjonalne — sprawdzają CECHY JAKOŚCIOWE systemu, a nie konkretną funkcję: użyteczność, wydajność, obciążenie, zgodność, bezpieczeństwo (szczegółowo w lekcji 6).

Metodyki testowania — sposób ORGANIZACJI procesu testowania w projekcie: testy MANUALNE (człowiek klika i sprawdza ręcznie wg scenariusza) kontra testy AUTOMATYCZNE (kod testujący kod, uruchamiany bez udziału człowieka, powtarzalny). W praktyce projektowej łączy się oba podejścia — testy automatyczne dla logiki i regresji, manualne dla oceny użyteczności i przypadków trudnych do zautomatyzowania.

Cykl życia błędu (bug lifecycle) — zgłoszony błąd przechodzi przez kolejne stany: Nowy (zgłoszony, jeszcze nieprzeanalizowany) → Przypisany (programista wie, że ma go naprawić) → W trakcie naprawy → Naprawiony (poprawka gotowa) → Do weryfikacji (tester sprawdza, czy poprawka faktycznie działa) → Zamknięty (potwierdzone, że błąd zniknął) — albo Otwarty ponownie, jeśli weryfikacja wykaże, że błąd nadal występuje. Ten cykl jest podstawą narzędzi takich jak JIRA czy BugZilla (lekcja 7).

Walidacja kodu (INF.04.8.1) to szerszy proces niż samo testowanie: obejmuje DOBÓR odpowiednich narzędzi (debugger, testy, analiza statyczna kodu), identyfikację błędów, ich poprawę oraz OPTYMALIZACJĘ kodu (żeby działał szybciej/czytelniej, nie tylko poprawnie).

Schemat

        ▲  Testy niefunkcjonalne
       /│    (użyteczność, wydajność,
      / │     obciążenie, bezpieczeństwo)
     /──┼──
    / Testy     Testy funkcjonalne
   /  funkc.    (cała funkcja z pkt. widzenia użytkownika)
  /────┼────────
 /  Testy          Testy integracyjne
/ integracyjne      (współpraca kilku elementów)
──────┼──────────────
   Testy jednostkowe    ← najwięcej, najszybsze,
   (pojedyncza metoda)     pierwsza linia obrony

CYKL ŻYCIA BŁĘDU:
Nowy → Przypisany → W trakcie naprawy → Naprawiony → Do weryfikacji → Zamknięty
                                                            │
                                                            └─ (jeśli nadal występuje) → Otwarty ponownie

Przykład z życia

Producent samochodów przed wypuszczeniem nowego modelu testuje go na wielu poziomach: pojedyncze elementy (hamulce, poduszki powietrzne — "testy jednostkowe"), współpracę układów (czy hamulce i ABS działają razem — "testy integracyjne"), całe auto w typowej jeździe ("testy funkcjonalne") i w warunkach ekstremalnych — zderzenia, mróz, upał ("testy niefunkcjonalne" — bezpieczeństwo i wytrzymałość). Oprogramowanie testuje się dokładnie w tej samej logice, tylko zamiast crash-testów mamy automatyczne programy sprawdzające kod.

Ćwiczenie samodzielne

Wypisz na kartce 3 funkcjonalności dowolnej aplikacji, którą znasz (np. sklep internetowy: logowanie, dodawanie do koszyka, płatność). Dla każdej zaproponuj po jednym przykładzie testu jednostkowego, integracyjnego i funkcjonalnego.

Zadania do pracy własnej

Wypisz różnice między testem jednostkowym a testem funkcjonalnym w formie tabeli (co sprawdzają, jak szybko się wykonują, jak często się je uruchamia).
Opisz krok po kroku cykl życia przykładowego błędu — od momentu, gdy użytkownik zgłasza "aplikacja się zawiesza po kliknięciu Zapisz", aż do jego zamknięcia. Wskaż, kto (użytkownik/programista/tester) odpowiada za każdy etap.
Zaproponuj plan testów (jakie rodzaje testów, w jakiej kolejności) dla prostej aplikacji kalkulatora z historią obliczeń zapisywaną w pliku. Uzasadnij, dlaczego akurat taka kolejność i zakres testów ma sens.

Typowe błędy

Traktowanie testowania jako czynności wykonywanej "na końcu, jeśli starczy czasu" — im później błąd zostanie wykryty (dopiero u klienta zamiast podczas pisania kodu), tym drożej i trudniej go naprawić.

Mylenie testów jednostkowych z testami funkcjonalnymi — test jednostkowy sprawdza JEDNĄ metodę w izolacji (np. czy Dodaj(2,3) zwraca 5), test funkcjonalny sprawdza CAŁY przepływ z perspektywy użytkownika (np. czy da się zalogować, dodać produkt do koszyka i złożyć zamówienie). To różne poziomy, oba potrzebne.

Zakładanie, że "program się kompiluje" oznacza "program działa poprawnie" — kompilacja sprawdza tylko POPRAWNOŚĆ SKŁADNIOWĄ kodu, nie sprawdza, czy logika biznesowa daje właściwe wyniki. Do tego służą właśnie testy.

Nawiązanie do egzaminu zawodowego

To wprowadzenie do całego działu INF.04.8 — pojęcia z tej lekcji (rodzaje testów, cykl życia błędu) będą używane we wszystkich kolejnych lekcjach, zaczynając od praktycznego narzędzia MSTest w Visual Studio (lekcja 2), przez zastosowanie w konkretnych typach aplikacji (WPF, MAUI, web — lekcje 3-5), aż po dokumentowanie i automatyzację (lekcje 8-9).