środa, 28 maja 2008

Test-driven development

Nie trzeba chyba mówić nikomu, jak ważne są testy oprogramowania. Każdy program, każda jego funkcjonalność powinny być przetestowane pod względem poprawnego działania. Czym byłby program gdyby nie dawał poprawnych wyników lub czas oczekiwania był na tyle duży, aby wyniki się dewaluowały. Program który jest poprawnie przetestowany na pewno oszczędzi wiele nerwów programistom, klient będzie zadowolony z braku błędów lub jej bardzo małej ilości i wszystko gra.

Sam proces testowania jest jednym z najżmudniejszych zadań w procesie produkcyjnym, zajmuje dużo czasu, a nie zawsze daje zadowalające wyniki. Często testowanie traktowane jest po macoszemu, robione tylko ogólnikowo dla wybranych funkcjonalności lub standardowych danych co tak naprawdę mija się z celem.

No dobra, rzeczywiście testowanie trzeba robić porządnie, ale jak?


Moja propozycja zapewne znana już większości to pisanie testów jednostkowych.
W TDD zazwyczaj pisze się test do danej funkcjonalności jeszcze zanim zaczniemy tą funkcjonalność implementować.

  • test określa nam wymagania algorytmu, jeśli napiszemy poprawnie test przedstawia on nam wymagania które musimy spełnić, od tej chwili nie musimy martwić się o spełnienie wymagań w algorytmie tylko o poprawne przejście testu przez algorytm

  • już na wstępie może pokazać gdzie wyłonią się możliwe problemy w implementacji,

  • w pewnym sensie motywuje do szybkiego a przy tym poprawnego pisania (w końcu algorytm musi przejść test) co zwiększa wydajność pracy

Każda róża ma kolce, tak i tutaj pojawiają się pewne minusy

  • niemal dwukrotnie więcej kodu do napisania

  • późniejsze zmiany w kodzie trzeba odzwierciedlić zmianami w testach co można by rozumieć jak prowadzenie dwóch projektów w jednym

Podstawowe zasady pisania testów
Metodologia pisania testów jest prosta. Piszemy test który sprawdza daną funkcjonalność pod względem poprawności algorytmicznej. Po czym implementujemy tą funkcjonalność tak aby przechodziła test. Cały kod pisze się w tak zwanych iteracjach:


Iteracje trwają zazwyczaj od kilku do kilkunastu minut w zależności od rozmiaru problemu. Cały kod uznaje się za poprawny jeśli przejdzie swój test. Koniec każdej iteracji powinien być zakończony przez pozytywne przejście testu.
Ważne jest aby kod źródłowy testów pisany był z równą dokładnością co kod źródłowy aplikacji, jest on tak samo ważny i nie powinien być traktowany po macoszemu.


Należy również pamiętać, że program który poprawnie przechodzi testy niekoniecznie może działać poprawnie. Zapytacie pewnie po co w takim wypadku pisać testy?
Otóż testy same w sobie pozwalają wykryć większość błędów programistycznych, a wykryty błąd jest natychmiastowo lokalizowany i opisany przez test.

Wyobraź sobie, że prowadzisz duży projekt. Projekt składający się z kilkunastu/kilkudziesięciu modułów które ze sobą współpracują. Projekt działa całkiem dobrze, jednak po kilku miesiącach szef kazał Ci zmienić jakąś funkcjonalność w jednym z modułów. Sama zmiana może i trwa kilka minut, ale z racji że jeden moduł jest zależny od drugiego nie jesteś pewien, czy ta zmiana nie pociągnie za sobą nieprzewidzianych problemów z modułami zależnymi. Rzadko się zdarza by programista pamiętał każdy aspekt pisanego programu, szczególnie gdy jest on rozbudowany. Jeden moduł może być wykorzystywany w wielu miejscach które trzeba sprawdzić.
Tu również z pomocą przychodzi pisanie testów. Jeśli będziemy stosować się do zaleceń TDD i każdy moduł/klasa będzie miała test, to taka poprawka nie stanowi dla nas najmniejszego problemu.
Wystarczy wprowadzić zmiany i uruchomić testy dla całego projektu. Jeśli jakaś nieścisłość występuje zostanie ona wykryta a programista powiadomiony o tym. Dzięki temu można zaoszczędzić naprawdę dużo czasu i nerwów.

Brak komentarzy:

Prześlij komentarz