#2 Antywzorce w testowaniu oprogramowania: Testy integracyjne bez testów jednostkowych

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

Wiemy już, dlaczego nie powinniśmy skupiać uwagi tylko i wyłącznie na testach jednostkowych. Ale jak to ze wszystkim bywa – nie można przesadzać w żadną ze stron. Dlatego dzisiaj porozmawiamy sobie o odwrotnej sytuacji, kiedy to zaniedbywane są testy zajmujące najniższy poziom piramidy.

Z poprzedniego wpisu o testach jednostkowych bez testów integracyjnych z serii o Antywzorcach płynie wniosek, że unitami po prostu nie jesteśmy w stanie zapewnić jakości w każdym aspekcie i dlatego powinniśmy zadbać o to, by nie były one samotne w swoim istnieniu :).Mało tego – z tabelki Kostisa Kapelonisa można łatwo wywnioskować, że testami integracyjnymi możemy nie tylko sprawdzić więcej aspektów jakości, niż jednostkowymi, ale z powodzeniem te pierwsze mogą zastępować drugie w testowaniu podstawowej logiki biznesowej. Dlaczego więc nie jest to dobry pomysł?

Less is more

Wróćmy w tym miejscu do tematu pokrycia testami. Załóżmy, że chcielibyśmy uzyskać 100% pokrycie logiki biznesowej modułów korzystając z testów jednostkowych i integracyjnych. Posłużmy się też przykładem z artykułu Kostisa Kapelonisa i załóżmy, że nasz program składa się z 4 modułów o określonej liczbie punktów decyzyjnych:

  • Moduł A – 2 punkty decyzyjne,
  • Moduł B – 5,
  • Moduł C – 3,
  • Moduł D – 2.

Korzystając z testów jednostkowych wystarczyłoby napisać izolowanych 12 testów (2 + 5 + 3 + 2) by w pełni pokryć logikę biznesową. Jeśli jednak zdecydujemy się na testy jednostkowe, to konieczne będzie stworzenie aż 60 testów (2 * 5 * 3 * 2)! Czyli potrzebujemy aż 5 razy więcej testów! Oczywiście, w pierwszym przypadku konieczne będzie napisanie tylko dodatkowych 1-3 testów integracyjnych (wszak nie przejmujemy się już logiką biznesową poszczególnych modułów), ale nadal będzie to stosunek 15 do 60.

Czas to pieniądz, a nie odmawia się, kiedy pieniądz woła

Sama natura testów jednostkowych zapewnia im pewien, nazwijmy to, przywilej szybkość wykonania. Potrzebny jest w zasadzie tylko kod źródłowy aplikacji i procesor 😉 Natomiast w przypadku testów jednostkowych konieczne może okazać sprawdzanie powiązań z innymi systemami czy bazami danych, a to powoduje znaczny wzrost czasu wykonania. Zwłaszcza, jeśli te dodatkowe systemu muszą zostać wcześniej wybudowane.

Z obliczeń Kostisa Kapelonisa – z wspominanrgo już wielokrotnie artykułu – wynika, że czas wykonania testów tylko integracyjnych to 6,4 minuty. Jeśli jednak w projekcie posiadamy fuzję testów jednostkowych i integracyjnych ten czas spada do przyjemnej 1,4 minuty. A to spora różnica, prawda?

Debugowanie i Utrzymanie

Dużo testów to dużo kodu do utrzymania. To również niemało kodu do przejrzenia w sytuacji, gdy testy, pisząc kolokwialnie, się wywalą. To spore uproszczenie. Ale pamiętając o tym, że testy integracyjne “przechodzą” przez wiele modułów, to kiedy test “się wywalił” nie jest łatwo określić, który dokładnie moduł zawiódł, zwłaszcza w przypadku bardzo skomplikowanych aplikacji. W przypadku testów jednostkowych ten problem znika – wiemy dokładnie która część wymaga poprawy, programista może otworzyć kod źródłowy dla nieszczęsnego modułu i po prostu go poprawić. Co przy okazji naprawi też testy 🙂

Podsumowując: rezygnacja z testów jednostkowych na rzecz tylko testów integracyjnych w celu uzyskania wysokiego pokrycia logiki biznesowej może po prostu na myśl przynosić strzelanie do komara z armaty – oczywiście, można to robić skutecznie, powstaje tylko pytanie, czy nie szkoda zasobów. To także znaczny wzrost czasu poświęconego na napisanie testów (musimy mieć ich więcej), wykonanie testów oraz debugowanie zarówno kodu źródłowego aplikacji, jak i samych testów (więcej testów – więcej kodu do przejrzenia).

Najnowsze wpisy

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?

Technologia po gruzińsku

Pozwolę sobie jeszcze na chwilę zanurzyć się we wspomnieniach i nieco przybliżyć Wam moją podróż. Żeby nie była to jednak zupełna prywata, to opiszę, co zaskoczyło mnie pod względem technologicznym.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!