Testowanie

Arkusze testowe

Arkusze testów (ang. unit tests) są jednym z kamieni węgielnych Extreme Programming (XP). Jednakże testowanie w XP nieco różni się od zwykłego. Najpierw tworzysz lub ściągasz środowisko, które pozwoli je przeprowadzać w sposób automatyczny. Następne powinieneś przetestować wszystkie klasy w systemie. Trywialne metody typu get/set są przeważnie pomijane. Później powinieneś już praktykować tworzenie testów przed właściwym kodem.

Arkusze testów są publikowane do repozytorium razem z kodem, który testują. Kod nie pokryty testami nie może być opublikowany. Jeśli odkryjemy, że jakiegoś testu brakuje, powinniśmy natychmiast go opracować.

Największą trudnością w prowadzeniu arkuszy testów jest nieubłaganie zbliżający się deadline, termin oddania efektów pracy. W praktyce jednak automatyczne testy potrafią zaoszczędzić stokroć tyle czasu ile potrzeba przeznaczyć na ich stworzenie poprzez wynajdywanie błędów i zapobieganie przez nimi. Im trudniej jest opracować dany test tym bardziej go potrzebujesz, gdyż zaoszczędzi więcej czasu później. Koszty potrzebne na tworzenie testów zawsze zwracają się z nawiązką.

Innym popularnym błędnym przekonaniem jest, że testy mogą być pisanie w ciągu trzech ostatnich miesięcy projektowania. Niestety - bez arkuszy testów - prace developerskie przeciągają się, pochłaniając i te trzy miesiące, a może nawet więcej... Nawet, gdy znajdzie się trochę dostępnego czasu trzeba się liczyć z tym, że aby powstałe dobre testy potrzeba trochę czasu. One muszą dojrzeć. Odkrywanie potencjalnych problemów, które mogą wystąpić pochłania dalszy czas. ?eby testy były dostępne, kiedy będą potrzebne powinieneś zacząć tworzyć je już teraz.

Arkusze testów wspierają zbiorową własność kodu. Kiedy tworzysz arkusze testów strzeżesz swoją funkcjonalność przed przypadkowymi uszkodzeniami. Wymagając, aby cały kod przeszedł wszystkie testy przed publikacją upewniasz się, że cała funkcjonalność systemu jest sprawna. Wydzielanie odpowiedzialności za kod nie jest potrzebne, jeśli na straży klas stoją odpowiednie arkusze testów.

Arkusze testów umożliwiają również refaktoryzację. Po każdej drobnej zmianie testy mogą ją zweryfikować i upewnić się, że zmiana w strukturze rozwiązania nie wpłynie na niepożądaną zmianę funkcjonalności.

Zbudowanie pojedynczego, uniwersalnego zestawu arkuszy testów do walidacji i testowania regresyjnego pozwala na częstą integrację kodu. Możemy wtedy szybko zintegrować wszystkie ostatnie zmiany, po czym uruchomić najnowszą wersję zestawu testów. Jeśli twój kod nie przejdzie testu, oznacza to, że jest niekompatybilny z poprzednią wersją. Usuwanie małych problemów, w co kilka godzin zabiera mniej czasu niż naprawianie olbrzymich tuż przed wyznaczonym terminem. Wykorzystując automatyczne testowanie jest możliwe dołączenie zbioru poprawek do ostatnio wypuszczonej wersji i opublikowanie ich w krótkim czasie.

Często dodawanie nowych funkcji będzie wymagać zmiany arkuszy testujących, aby te ogarnęły zmienioną funkcjonalność. Choć jest możliwe wprowadzenie błędu zarówno do kodu jak i do testu, w praktyce zdarza się to rzadko. Czasami test będzie błędny, ale kod okaże się poprawny. Ujawni się to dopiero, gdy problem będzie już wykryty i naprawiony. Tworzenie arkuszy testów niezależnie od kodu, najlepiej jeszcze przed nim, wyznacza ramy zadania i znacznie zwiększa szanse na jego dobrą implementację już za pierwszym razem.

Arkusze testujące zapewniają bezpieczną sieć testów regresyjnych i zatwierdzających, dzięki czemu możesz refaktoryzować i integrować kod bardzo efektywnie. Jak mówią w cyrku: nigdy nie pracuj bez siatki! Tworzenie arkuszy testów przed kodem ma jeszcze dodatkowe zalety: utrwala wymagania i pozwala na skupienie się developerów na konkretnym problemie.

Schematy arkuszy testujących

Jednym z najczęściej spotykanych błędów jest rozumienie schematów arkuszy testujących dosłownie - jako narzędzi testujących. Są to narzędzia rozwojowe, podobnie jak edytor czy kompilator. Nie odkładaj użycia tego potężnego narzędzia aż do ostatniego miesiąca projektu - używaj go przez cały czas tworzenia. Schematy te pomogą ci ustalić wymagania,uczynić architekturę bardziej przejrzystą, napisać, debugować i zintegrować kod, opublikować, zoptymalizować i, oczywiście przetestować.

Schematy arkuszy testujących można łatwo stworzyć od podstaw, ale większość języków ma taki schemat już utworzony i dostępny w formie do ściągnięcia na XProgramming.com.

Gdy znajdziemy błąd

Po ujawnieniu się błędu tworzone są testy. Mają one ostrzegać przed jego ponownym jego wystąpieniem. Błąd w wykonaniu wymaga testu akceptacyjnego, który będzie sprawdzał nasz system pod jego kątem. Testy akceptacyjne tworzone jako pierwsze, jeszcze przed samym debugowaniem pozwalają użytkownikom na zwięzłe zdefiniowanie problemu i przedstawienie go programistom. Programiści mając wyszczególniony niespełniony test mogą wtedy skoncentrować swoje siły na rozwiązywaniu problemu i wiedzą kiedy efekt zostanie osiągnięty.

Otrzymawszy niezdane testy akceptacyjne, developerzy mogą utworzyć mniejsze arkusze testujące, aby móc opisać defekt za pomocą większej ilości kodu i ukazać błąd z różnych punktów widzenia, w różnym kontekście. Obserwując interesujące nas arkusze testów możemy na bieżąco kontrolować, kiedy błędy zostaną poprawione. Gdy wszystkie arkusze przechodzą testy pomyślnie możemy ponownie uruchomić odpowiednie testy akceptacyjne by upewnić się, że problem na pewno został zażegnany.

Testy akceptacyjne

Testy akceptacyjne tworzone są na bazie opowieści użytkowników. Podczas iteracji opowieści użytkowników (wcześniej wybrane podczas spotkania planującego iterację) zostaną przetłumaczone na testy akceptacyjne. Kiedy opowieść zostanie prawidłowo zaimplementowana, użytkownik precyzuje scenariusz testu. Dana opowieść może mieć jeden lub więcej testów akceptacyjnych - tyle, aby mieć pewność, że funkcjonalność będzie działać prawidłowo.

Testy akceptacyjne to czarne skrzynki testów systemowych. Każdy z tych testów ma za zadanie podać pewien oczekiwany wynik systemowy. Użytkownicy odpowiedzialni są za sprawdzanie prawidłowego przebiegu testów, a także za przegląd ich wyników. Te informacje pomagają im zdecydować o tym, które z oblanych testów są najważniejsze (najwyższej wagi). Testy akceptacyjne są także używane jako testy regresyjne stosowane jeszcze przed publikacją projektu.

Opowieść użytkownika nie jest uważana za kompletną, zanim nie przejdzie testów akceptacyjnych. Oznacza to, że dla każdej iteracji należy stworzyć nowy test akceptacyjny. W przeciwnym wypadku zespół developerów ogłosi zerowy postęp.

Gwarancja jakości (ang. quality assurance - QA), jest zasadniczą częścią programowania w XP. Przy niektórych projektach QA jest przeprowadzana przez członków specjalnie do tego powołanej grupy, podczas gdy przy innych - grupa ta jest po prostu częścią grupy developerskiej.

Testy akceptacyjne powinny być zautomatyzowane po to, by można je często uruchamiać. Wynik testu akceptacyjnego ogłaszany jest zespołowi, którego zadaniem jest takie zaplanowanie czasu każdej iteracji, by poprawić wszystkie z oblanych testów. Testy akceptacyjne poprzednio nazywane były testami funkcjonalnymi.

Nazwa ta została zmieniona na obecną, ponieważ lepiej oddaje ona cel testów, co daje gwarancję, że oczekiwania użytkowników zostaną w pełni zaspokojone a system we właściwy sposób spełnia swe zadania.