Każdy program, każda jego funkcjonalność powinny być przetestowane po
d względem poprawnego działania. Sam proces testowania jest jednym z najżmudniejszych zadań w procesie produkcyjnym, zajmuje dużo czasu, a nie zaw
sze daje zadowalające wyniki. Ponadto brak testów powoduje, że spada jakość oprogramowania. Jak temu przeciwdziałać? Pewną odpowiedzią jest wytwarzanie oprogramowania w oparciu o testowanie. Taki też by temat dwudniowych warsztatów (spotkania coach’ingowego) jakie prowadziłem 23-24 czerwca w Warszawie. Spotkania te były ukierunkowane na wytwarzanie oprogramowania w oparciu o testowanie, ale stanowiły także podsumowanie dwóch innych sesji, które dotyczyły odpowiednio: modelowania biznesowego (12.05.2008) i analizy i projektowania systemów informatycznych (17.06.2008).
Podejście oparte na testowaniu pochodzi wprost z Extreme Programming, o którym pisałem tutaj. Ciągłe testowanie to podstawowe działanie podczas pisania programu w metodzie XP. Programista jeszcze przed napisaniem danej procedury tworzy kod, który ma ją testować. W ten sposób wcześniej musi pomyśleć o wszystkich rzeczach, które mogą ’pójść źle’. Dzięki temu podczas pisania właściwego kodu procedury zabezpieczy ją przed tymi możliwościami. TDD nakazuje nam, aby test był niewielki, odnoszący się do niewielkiej części kodu. Napisany i zdany test jednostkowy pozwala przejść do fazy refactoringu. Co istotne, refaktoryzacji podlegać mogą także testy a cały cykl test-code-refactor powinien zająć około 10 minut. Według tego podejścia takie małe testy są bardzo ważne i radykalnie poprawiają jakość oprogramowania. Niestety nadal cięzko jest testować GUI oraz aplikacje wielowątkowe a także mimo bibliotekom Hibernate i Spring kuleje testowanie baz danych.
W czasie tego szkolenia – spotkania coach’ ingowego sporo dykutowaliśmy o zaletach i wadach tego podejścia w kontekście podejścia ukierunkowanego na przypadki użycia. Co ciekawe jedno nie wyklucza drugiego. Do wad tej metody zaliczyliśmy:
- ilość kodu - niemalże dwukrotnie więcej,
- zmiany w kodzie, które trzeba odzwierciedlić zmianami w testach co może wyglądać jak prowadzenie dwóch projektów w jednym,
- dokumentacja – a raczej jej brak, chyba, że ktoś umie czytać kod testów
Natomiast do zalet:
- redukcja czasu wyszukiwania błędów już napisanego kodu
-
krótszy czas implementacji
-
pokrycie kodu testami większe
Podsumowując szkolenie to uważam za bardzo ciekawe. Opinie tą także potwierdza ankieta, w której szkolenia i ja otrzymalismy same dobre i bardzo dobre noty.
