Dlaczego unikamy pisania automatycznych testów?

źródło: http://vfxstudios.net/portfolio/3d-character-design-rae/3d-character-rae.html

Ostatnio odbyłem bardzo ciekawą rozmowę z kolegą z pracy, która dotyczyła automatyzacji testów. Powodem tej dyskusji była duża liczba błędów, w jednym z modułów naszej aplikacji, za którą kolega był odpowiedzialny.Błędy te powstawały głównie ze względu na duże zmiany w istniejącym już kodzie wymuszone zmianą wymagań i refaktoryzacją. Osoby, które mnie znają zapewne zgadną jakie było moje pierwsze pytanie. Oczywiście było to:

A gdzie się podziały wszystkie testy w tym module?

Okazało, się, że jako jedyny z dostępnych modułów w naszej aplikacji nie posiadał on w ogóle żadnych automatycznych testów. To oczywiście nie znaczy, że w pozostałych modułach nie występują błędy, ale jest ich zdecydowanie mniej.

Kolega tłumacząc się odpowiedział, że nie miał po prostu na to czasu. Hmm, nic nowego, już chyba po raz setny słyszę tego typu odpowiedź. Kontynuując zapytałem się czy jego zdaniem testy automatyczne mają sens. I tutaj się ucieszyłem, bo kolega odpowiedział, że tak. Więc idąc za ciosem wdałem się w dyskusje z nim pytając, dlaczego ich nie pisze, jeżeli jest przekonany, że mają sens. Z dyskusji tej wynikły następujące wnioski, z którymi chciałbym się z wami podzielić.

Większość programistów za główną wadę pisania automatycznych testów – przede wszystkim jednostkowych, uważa potrzebę poświęcenie dodatkowego czasu na napisanie tych testów. Z drugiej strony wydaje mi się że każdy kto przynajmniej parę razy w życiu refaktoryzował istniejący kod, nie mając w zapasie testów potwierdzających poprawność kodu, chyba przyzna mi rację, że tego typu refaktoryzacja to po prostu katorga. Uważam, że w większości przypadków brak automatycznych testów jest jednym z głównych powodów, dlaczego rezygnujemy z poprawiania działającego ale nie czytelnego kodu. Patrząc na to łatwo można dojść do wniosku, że jeżeli chcemy utrzymywać porządek w naszym kodzie, to wymagane jest od nas utrzymywanie testów automatycznych, które w każdej chwili możemy uruchomić po to, by sprawdzić czy wszystko nadal działa poprawnie.

W wielu przypadkach programiści piszą testy dopiero po napisaniu funkcjonalności, która ma być przetestowana. Przyznam się szczerze, że czasami mi się to również zdarza, rzadko ale się zdarza. W przypadku gdy dopisuje test już po zaimplementowaniu funkcjonalności, czuję pewną niechęć i brak potrzeby pisania tego testu. Dzieje się tak głównie dlatego, że jestem zbyt pewny siebie (a może zbyt leniwy) i uważam, że napisany raz przeze mnie kod jest już poprawny. W wielu przypadkach jednak się mylę. W najgorszych przypadkach dochodzi do tego, że wkrada się błąd w kodzie dlatego, że pominąłem test. Jako, że życie mnie już pokarało parę razy za tego typu podejście, staram się pisać testy zawsze przed implementacją funkcjonalności. Poza tym pisanie testów po to dla mnie i dla wielu programistów jest jednym z najbardziej wkurzających zajęć. Jeżeli dodatkowo „ciśnie nas termin” w większości przypadkach zrezygnujemy z pisania testów po implementacji, dlatego, że traktujemy to jako marnotrawienie naszego cennego czasu. Jeżeli się zgadzacie z tym stwierdzeniem to zastanówcie się czy nie jest to dla was tylko dodatkowa wymówka na to, by się wywinąć z pisania testów?

Jeżeli rzeczywiście macie takie odczucie, to mam dla was małą oczywistą radę. Zaczynajcie pisanie kodu od napisania testu. Oczywiście to zajmie wam dodatkowy czas i początkowo trudno wam będzie wyszacować czas, który będzie potrzebny na realizację zadania. Z drugiej strony pisząc test przed napisanie funkcjonalności nie będziecie tak szybko rezygnować z pisania testów automatycznych. Za tym idzie z kolei to, że szybciej poznacie rzeczywistą wartość testów automatycznych, a w przyszłości będziecie też wam łatwiej wyszacować czas potrzebny na napisanie funkcjonalności wraz z testami.

Dla osób, które nie wiedzą jak zacząć z TDD polecam listę webcastów opublikowaną przez Łukasza. Przede wszystkim polecam webcasty z DNR TV w wykonaniu Jean Paul Boodhoo – sam z nich niejednokrotnie korzystałem, aby poznać TDD.