#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

test:fest 2019 – podsumowanie

Czas na recenzję Test:fest – bez wątpienia jednego z bardziej rozpoznawalnych testerskich wydarzeń w Polsce.

Quality Meetup #19 – podsumowanie

Już ponad miesiąc minął, odkąd wystąpiłam na Quality Meetup ze swoją prezentacją poświęconą błędom poznawczym. A jeszcze więcej od ostatniego wpisu na blogu. Czas najwyższy więc na dobre wyjść ze snu zimowego i zacząć nadrabiać.

CzytanQA: Duch w sieci

Gdyby ktoś zapytał mnie o największego trolla w historii IT, to bez mrugnięcia okiem odpowiedziałabym: Kevin Mitnick. A jego autobiografia, napisana wespół z Williamem L. Simonem jest tego najlepszych dowodem.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!