#1 Antywzorce w testowaniu oprogramowania: Testy jednostkowe bez testów integracyjnych

19 sierpnia 2018 | Trochę teorii, Uczymy się!

Przy takich upałach naprawdę ciężko jest się zmotywować do regularnego pisania 🙂 Ale wakacje trwać wiecznie nie mogą, a w sumie zaczyna mi już brakować pisania. Dlatego nadszedł czas by wreszcie zakasać rękawy i napisać pierwszy z serii wpis o antywzorcach w testowaniu oprogramowania.

Wstęp do serii wraz z listą antywzorców poczyniłam miesiąc temu we wpisie: Antywzorce w testowaniu oprogramowania. A dziś porozmawiamy sobie o tym, dlaczego posiadanie testów jednostkowych z pominięciem testów integracyjnych to nie najlepsza praktyka.

Zdarza się, że w firmie (a w większych firmach w niektórych zespołach) praktykowane jest pisanie tylko i wyłącznie testów jednostkowych, czyli tych znajdujących się u podstawy piramidy testów. Znam nawet testerów, którzy bronią takiego podejścia. I o ile dobre praktyki nakazują, że właśnie tych testów powinno być najwięcej, o tyle nic nie wspominają o tym, że testy jednostkowe wystarczą.

Czasami jako argument dla skupienia się na unit testach podawane jest całkiem niezłe (a w skrajnych przypadkach nawet stuprocentowe) pokrycie kodu testami. No bo jakby się uprzeć, zastosować odpowiednie narzędzia to pokrycie będzie ładnie wyglądało na papierze (czy na monitorze). Znajdą się i tacy, dla których jest to zwyczajnie wygodne – testy jednostkowe wymagają mniej zachodu, są łatwiejsze w utrzymaniu, nie musimy aż tak przejmować się środowiskiem testowym – jego konfiguracją i utrzymaniem. Dochodzi do tego aspekt przełączania się między zadaniami – jeśli ta sama osoba tworzy kod i sprawdzające go testy jednostkowe, to jest spora szansa, że zaoszczędzimy niemało czasu. Sporo czasu zaoszczędzimy też na samym odpalaniu testów, ponieważ testy jednostkowe zwykle wykonują się najszybciej. A jeśli testy jednostkowe to jedyne, jakie mamy na projekcie, to niekoniecznie jest też potrzebny tester – można zaoszczędzić na zasobach.

Same plusy? Z pozoru tylko. Bo choć testy jednostkowe dają fajne pokrycie, to nie są w stanie wykryć sporej ilości problemów. Przykład? Wystarczy spojrzeć na poniższą tabelkę (źródło):

Rodzaj problemuMożliwość wykrycia przez testy jednostkoweMożliwość wykrycia przez testy integracyjne
Błędy w podstawowej logice biznesowejtaktak
Problemy z integracją komponentównietak
Wymiana danychnietak
Połączenia z bazami danychnietak
Niepoprawne połączenia z innymi modułami/APInietak
Niepoprawne połączenia z innymi systemaminietak
Wydajność i timeoutynietak
Zakleszczenia (Deadlock/Livelock)możliwetak
Podstawowe kwestie bezpieczeństwanietak

Tabelka może pozwolić wysnuć jeden prosty wniosek: jeśli interesuje nas przekrojowa jakość naszej aplikacji (a pewnie tak, jeśli w ogóle interesuje nas jakość aplikacji), to testy jednostkowe mogą okazać się niewystarczalne. Posiadając tylko takie testy możemy dowiedzieć, się, czy uzyskaliśmy poprawność na najniższym poziomie, ale nie jesteśmy w stanie sprawdzić wielu innych aspektów jakości. A już na pewno nie wiemy, czy spełniane są oczekiwania użytkownika.

Najnowsze wpisy

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!