Spotkałem się z różnymi opiniami na ten temat. Sam zaraz po studiach opierałem się testowaniu automatycznemu. Sądziłem, że to skomplikowana tematyka. Myślałem, że są ważniejsze tematy do nauki, odkładałem rozpoczęcie przygody z testami automatycznymi na później. Myliłem się i trochę żałuje, że nie nauczyłem się pisania testów wcześniej. Ułatwiło by mi to znacząco pracę.

Przeciwko pisaniu testów automatycznych, najczęściej usłyszymy następujące argumenty:

  • To podwójna praca, dodatkowy poświęcony czas
  • Dodatkowa nauka,
  • I tak nie ma możliwości wyeliminowania wszystkich błędów,
  • Problem z utrzymaniem testów, ich częsta refaktoryzacja.

Dla mnie te argumenty z czasem przestały istnieć. Przeczytałem książki, artykuły, obejrzałem kursy. Brałem udział w szkoleniu, zorganizowanym przez firmę w której pracuję. Szkolenie było prowadzone przez firmę Bottega, trenerem był Maciej Aniserowicz (devstyle.pl).

Przyjrzyjmy się argumentom przeciw wprowadzeniu do projektu testów automatycznych, które przytoczyłem powyżej.

 

To podwójna praca, dodatkowy poświęcony czas

Może się tak wydawać. Ale pisząc testy automatyczne zaoszczędzamy tak naprawdę dużo czasu. Jesteśmy w stanie sprawdzić pisaną przez nas funkcjonalność bez uruchomienia systemu. Nie musimy przechodzić przez kolejne ekrany interfejsu użytkownika aby wpisać dane wejściowe i zobaczyć rezultat. Następnie wrócić do edytora, zmienić kod i powtórzyć cały proces od nowa. Każda zmiana kodu może wpłynąć na zachowanie systemu przez co powinniśmy za każdym razem testować całą funkcjonalność od nowa. Proces ten generuje bardzo dużo niepotrzebnej pracy. Pisząc test skracamy znacząco ten proces. Podajemy warunki początkowe i sprawdzamy poprawność wykonania.

Dla danej funkcjonalności powstanie cały zestaw testów. Znacząco ułatwi on wprowadzanie zmian czy rozbudowę funkcjonalności, wynikającą z ewolucji systemu. W przypadku edycji kodu uruchamiamy zestaw testów i wiemy czy wszystko działa według naszych oczekiwań. Dodatkowo jeżeli mamy pokrytą testami większość systemu dowiadujemy się czy nowa funkcjonalność lub jej zmiana nie wpływa negatywnie na inne miejsca w naszej aplikacji. Taki przypadek jest trudny do wychwycenia, gdy stosujemy tylko testy manualne. Najczęściej dopiero testerzy lub użytkownicy końcowi znajdą ten problem. Często odbywa się to po pewnym czasie.

Pracując w zespole może odbywać się podział zadań związanych z jedną funkcjonalnością. Przez co osoba zajmująca się back-endem nie da rady w inny sposób niż poprzez napisanie testów sprawdzić poprawność swojego kodu. Manualne testy możliwe stają się dopiero po połączeniu kodu z front-endem. Gdy to nastąpi najczęściej wykonywane już jest inne zadanie. Chyba nie muszę wspominać, że brak sprawdzenia poprawności swojego kodu w sposób automatyczny czy manualny to nie profesjonalne zachowanie.

 

Dodatkowa nauka

 Z tym argumentem trudno się nie zgodzić. Pisane testów automatycznych wymaga dodatkowej nauki a potem sporo praktyki. Jednak osoba, która zdecydowała się zostać programistą powinna wziąć pod uwagę fakt, że nieodłączną częścią tego zawodu jest ciągła nauka i rozwój. Więc jeżeli chcemy być profesjonalistami powinniśmy poszerzać swoją wiedzę.

 

I tak nie ma możliwości wyeliminowania wszystkich błędów

To prawda pisanie testów nie gwarantuje bezbłędnego kodu. Jednak w większości przypadków będzie ich mniej. Szczególnie, gdy stosujemy TDD(Test-Driven Development)

Dobrą praktyką w przypadku pojawienia się błędu jest napisanie testu, który go obrazuje. Kolejnym krokiem jest edycja kodu i sprawdzenie czy test przeszedł. Dzięki temu, że mamy testy nie musimy się martwić czy zmiany w kodzie wpłyną negatywnie na inne części systemu. Pisząc test dla błędu, daje nam pewność, że on się już nie pojawi.

 

Problem z utrzymaniem testów, ich częsta refaktoryzacja.

Zgadzam się z tym, że utrzymanie testów jest to pewien dodatkowy koszt. Szczególnie na początku nauki. Jednak zalety z posiadania testów są tak ogromne, że ten dyskomfort jest do zaakceptowania. Wraz z nabytym doświadczeniem i wiedzą związaną z testami automatycznymi ich utrzymanie staje się trywialnym i szybkim procesem. Pomagają w tym wzorce, które omówię w jednym z wpisów.

 

Zalety testów automatycznych

Największą zaletą posiadania testów to pozbycie się strachu przed refaktoryzacją kodu. Dzięki temu, że mamy zestaw testów, któremu ufamy, możemy bez obawy zmieniać istniejący kod. Polepszać jego czytelność, sprawiać aby był wydajniejszy nie przejmując się, że zepsujemy funkcjonalność systemu. Przez to system nad którym pracujemy będzie lepszej jakości. Co z kolei przyśpiesza wprowadzanie zmian i dostarczanie nowych funkcjonalności.

Pisanie testów pozytywnie wpływa na architekturę rozwiązania problemu domenowego. Znikają ciężkie do zrozumienia i utrzymania monolity. Kod jest podzielony na mniejsze fragmenty, które są osobno pokryte testami. Strukturalne podejście zmienia się w obiektowe. W związku z tym, wraz z rosnącym doświadczeniem, programiści wykorzystują coraz więcej wzorców projektowych. Przez co kod jest prostszy w utrzymaniu i zrozumieniu.

Zwróćmy jednak uwagę na fakt, że testy wpływają na jakość naszej pracy w sposób pośredni, nadal jesteśmy zobligowani do pisania jak najlepszego kodu, dodatkowo musimy także zadbać o zestaw testów. Pisanie testów nie zwalnia nas z polepszania swojego warsztatu.

Należy pamiętać również o tym, że testy sprawdzają spełnienie oczekiwań użytkownika. Funkcjonalność systemu tworzymy z myślą o użytkownikach. System ma za zadanie wspieranie, przyśpieszenie, uproszczenie codziennej pracy wielu ludzi.

 

Podsumowanie

Testy wnoszą dużo do projektu. Koszt związany z ich utrzymaniem i wdrożeniem jest coraz niższy wraz z wzrostem doświadczenia oraz wiedzy o tym jak pisać DOBRE testy. System pokryty testami staje się z czasem coraz lepszy. Programiści nie boją się go ulepszać gdy wzrośnie ich wiedza o domenie problemu rozwiązywanego przez oprogramowanie, które tworzą. Przekłada się to na szybkie dodawanie nowych funkcjonalności oraz zmianę istniejących. Czego oczekuje od nas biznes.

Mam nadzieję, że was przekonałem do pisania testów. W serii moich wpisów na ten temat przedstawię podstawy wystarczające aby rozpocząć własną przygodę z testami.

Po wprowadzeniu podstaw przedstawię rady jak tworzyć testy do istniejącego oprogramowania. Oraz omówię technikę tworzenia oprogramowania kładącą silny nacisk na testy o nazwie Test-Driven Development.

2 thoughts on “Czy warto pisać testy automatyczne?”

  1. Interesujący wstęp. Czekam na kolejne wpisy:) Zapisałem się do newslettera więc mnie nic nie ominie 🙂

  2. Fajny wpis. Powiem szczerze, że dałeś mi do myślenia. Zacznę naukę o testach i sprawdzę, czy rzeczywiście się tak sprawdzają.

Comments are closed.