W poprzednim poście pisałem ogólnie o testach integracyjnych. Dzisiaj zajmiemy się pierwszym podejściem – top-down.

W podejściu top-down najpierw wykonywane są testy punktów wejściowych (entry point) a następnie tester doczepia stopniowo kolejne moduły. Punktem wejściowym dla poniższego systemu jest węzeł M1. Testowanie M1 odbywa się na zasadzie testu jednostkowego. Z tego względu M2 oraz M6 muszą być zastąpione obiektami mock. Kolejnym etapem jest przetestowanie węzła M2. W tym przypadku M3 i M5 muszą być zamienione na obiekty mock. Ostatnim etapem w podejściu jest przetestowanie całego systemu bez obiektów mock. Bardzo ważne jest aby nie testować od razu całości a jedynie pojedyncze węzły. Wszelkie połączenia należy zastępować zatem prostymi mock’ami. Dzięki temu, w przypadku błędów tester wie, które miejsca podejrzane są o wystąpienie tego problemu. Rozszerzając system stopniowo (zastępując mock’i prawdziwymi obiektami) jest pewne, że ewentualne błędy znajdują się w ostatnio doczepionym węźle.

Etapy testów:

Zaprezentowane wyżej podejście, jest tzw. integracją wszerz. Można również wykonać integrację w głąb przechodząc kolejno przez M1, M2, M3, M4, M5, M6, M7. Wybór metody zależy od struktury modułów w systemie jednak nie ma to większego znaczenia ponieważ oba sposoby należą do testów typu top-down i mają tą samą wadę – obowiązek tworzenia obiektów mock. Zaletą podejścia top-down jest fakt, że nie trzeba tworzyć sterowników testu (kodu, który wywołuje odpowiednie moduły). Rolę sterownika odgrywa rzeczywisty moduł. Przykładowo, sterownikiem w etapie pierwszym, na powyższych rysunkach jest moduł M1.

Testy jednostkowe testują wyłącznie lokalne wykonywanie metod i jest nawet niewskazane aby testowane metody odnosiły się do zewnętrznych, zdalnych zasobów.Rozbudowane systemy są często rozproszone, działające na wielu komputerach oraz składających się z wielu modułów. Podstawowe pytanie brzmi: Jak sprawdzić czy utworzone moduły współpracują ze sobą? Otóż należy przeprowadzić testy integracyjne zgodnie z wybraną metodyką.

Testy integracyjne tak jak testy funkcjonalne powinny być przeprowadzane na bieżąco. Nie powinno czekać się z testami integracyjnymi aż do momentu kiedy wszystkie moduły będą ukończone – wtedy ciężej zlokalizować połączenia oraz na wszelkie zmiany architektoniczne może być już za późno.

Po walidacji logiki zawartej w pojedynczych modułach przychodzi czas na sprawdzenie połączeń między pakietami. Wykonanie testów integracyjnych może nastąpić wyłącznie po prawidłowej weryfikacji kodu przez testy jednostkowe. Jeśli występuje błąd na poziomie metod (testy jednostkowe), tym bardziej będzie występował na poziomie całych pakietów.

Przed rozpoczęciem jakichkolwiek testów integracyjnych należy zidentyfikować wszelkie połączenia między modułami. Powyższy diagram przedstawia fikcyjny system – grupę modułów z odpowiednimi relacjami.Przez moduł rozumie się zarówno klasę jak i bibliotekę. Stopień przyjętego rozdrobnienia zależy od testera. Z praktyki wynika, że należy przyjąć kryterium logiczne czyli podzielić system na pewne fragmenty funkcjonalne. Czasami testowanie pojedynczych klas nie ma sensu ponieważ są one zbyt mało skomplikowane i prawdopodobieństwo wystąpienia błędu związanego z integracją jest niskie.

W testach integracyjnych wykorzystuje się obiekty Mock. Skuteczność zależy niestety w dużej mierze od architektury systemu. Jeśli wykorzystywaliśmy IoC będzie nam dużo łatwiej testować system poprzez odłączanie kolejnych modułów. Istnieje kilka podejść do testowania – ale o tym w następnych poście!