Kilka słów o tym dlaczego pisanie testów jednostkowych to strata naszego czasu

Pisząc kod aplikacji w JavaScript czy w innym języku programowania często spotykamy się z podejściem, w którym wymagane jest pisanie testów jednostkowych przed rozpoczęciem pisania kodu aplikacji. Uważam, że to podejście się nie sprawdza.

Kiedy pisanie testów jednostkowych jest zbędne?

Każdy kto pisał testy jednostkowe, to wie że napisanie testów które dobrze przetestują kod (który napisaliśmy) zajmuje trochę czasu. Często bywa tak, że zajmuje to drugie tyle czasu ile poświęciliśmy na pisanie kodu. To jest kompletna strata czasu, który może być lepiej spożytkowany.

Jest to kompletna strata czasu w przypadku, gdy pracujemy nad jakimś prototypem aplikacji, bądź po prostu na szybko sprawdzamy jak działa nowa technologia. Na szczęście, nie spotkałem się z podejściem, że ktoś wymaga pisania kodu testów do wszystkiego co robimy. W moim przypadku, odpuszczam pisanie testów jednostkowych tylko wtedy, gdy wiem, że nie planuję poświęcić dużo czasu jakiemuś prototypowi. Przez ten czas mógłbym wymyślić zupełnie inny prototyp, który lepiej spełni założenia.

Nie da się ukryć, że czasem bywa tak iż poświęca się czas potrzebny na pisanie testów w celu szybszego dostarczania nowych funkcjonalności aplikacji. Dzięki temu, tzw. biznes jest szczęśliwy, bo mają kolejny punkt na liście to-do odhaczony. A dług technologiczny rośnie.

Poza tym, pisanie testów jednostkowych jest nudne!

A może jednak powinniśmy pisać testy?

Z drugiej strony pisanie testów jednostkowych może nam uratować skórę. Gdy już pracujesz nad jakimś produktem profesjonalnie, to wskazane jest, aby pisać testy. Na przykład, gdy napiszesz testy jednostkowe w JavaScript to możesz być pewien/pewna, że coś zostało przetestowane. Lecz czy zostało to poprawnie przetestowane to już inna bajka. Bo testy jednostkowe łatwo można napisać tak, że niby coś testują, ale jednak jakby nie do końca. Wtedy takie rzeczy wychodzą podczas procesu zwanego code review.

Pytanie, kiedy pisanie testów jednostkowych ułatwi nam życie i sprawi, że czas poświęcony na ich pisanie nie będzie straconym czasem?

Po pierwsze, testy jednostkowe same w sobie sprawdzają tylko i wyłącznie jeden komponent/element aplikacji. Pisząc taki test, możemy mieć zabezpieczenie, że w określonych sytuacjach kod zachowa się w taki a nie inny sposób. Testy jednostkowe nie powiedzą nam, czy dany kod przy współpracy z innymi komponentami/elementami będzie działał poprawnie. Wiedząc, że mamy testy dla wybranego elementu aplikacji, możemy w miarę bez obaw zająć się refaktorowaniem kodu (jeśli jest potrzeba). Dzięki nim, możemy być pewni, że jeśli zepsujemy zachowanie komponentu wprowadzając nowy bądź ulepszony kod, to podczas uruchamiania testów to wyjdzie.

Druga rzecz, pisanie testów bardzo ułatwia pisanie kodu, który jest czytelny i nie zawiera zbędnego kodu. Dzięki temu, możemy zmniejszyć ryzyko, że do finalnej wersji aplikacji wejdzie kod, który jest nieużywany, bądź nieczytelny. Nie ma nic gorszego niż powrót do takiego kodu po dłuższej przerwie i zacząć się zastanawiać: Co autor miał na myśli? Tym bardziej, jeśli nad danym kawałkiem pracuje wiele osób na przestrzeni czasu. Warto likwidować ryzyko straty czasu na ponowne zrozumienie niezrozumiałego kodu.

Po trzecie, pisząc testy jednostkowe zwiększamy pewność, że napisaliśmy kod który spełnia w jakimś stopniu wymagania projektowe aplikacji.

Podsumowanie

Swego czasu na MeetJS Katowice, prowadziłem prezentację dotyczącą tematu testowania kodu JavaScript. W jej trakcie opisałem co się dzieje, gdy piszemy testy a co się dzieje gdy ich nie piszemy. Myślę, że warto sobie przejrzeć slajdy z tej prezentacji.

Podsumowując, testy jednostkowe warto pisać wszędzie tam, gdzie możesz wrócić do danego kawałka kodu w przyszłości. Unikniesz wtedy nieoczekiwanych problemów związanych z czytelnością kodu czy też dodawaniem nowych funkcji. Natomiast, nie przejmowałbym się nimi w przypadku szybkich prototypów lub w trakcie sprawdzania nowych technologii, które ewentualnie mógłbyś/mogłabyś wykorzystać w swoich priorytetowych projektach.

Tak jest na przykład ze mną i projektem League Managera. To jest prototyp, nad którym ciągle trwają prace, aby zaimplementować bazowe funkcjonalności i wcale nie jest powiedziane, że będę potem wracał do tego kodu.

Jeśli masz jakieś ciekawe sugestie czy chcesz się podzielić doświadczeniem w kwestii pisania testów jednostkowych to zapraszam do komentowania. Warto uświadomić niektórych programistów, że warto to robić.