Testy jednostkowe – warto czy nie warto?

Każdego dnia słyszę w biurze rozmowy i głosy typu:

„Człowieku, kocham testy jednostkowe! Codziennie dokonuje mnóstwa zmian w kodzie, żeby coś działało. Dalej potwierdzam, że nie zepsułem czegoś, właśnie dzięki uruchamianych ciągle testom…”

Szczegóły zmieniają się codziennie, ale przyzwyczajenia niekoniecznie. Testy jednostkowe i programowanie wsparte testami (ang. Test-driven development) dają tak wiele korzyści, jawnych lub bardziej ukrytych, że trudno o łatwe wyjaśnienie, gdy ktoś nigdy z nich nie korzystał.

Dlaczego ignorowanie testów jest dużym błędem.

1. Testy jednostkowe pozwalają na duże zmiany w kodzie w szybkim czasie. Masz pewność, że coś działa, bo testy wykonują się poprawnie. Dokonujesz koniecznych zmian, a ponownie uruchomione testy nie zgłaszają błędów. To oszczędza czas.
2. TDD pomaga w rozsądnym programowaniu. Kiedy testy działają kończysz implementowanie danej funkcjonalności. Testy pozwalają na spokojne przechodzenie do kolejnych etapów projektu bez lęku pozostawienia niekompletnego kodu.
3. Testy i implementacja pozostają bardzo blisko siebie, aby wynikowy kod był lepszej jakości. Twój kod bywa zły oraz zawiera błędy. Twoje testy bywają złe i zawierają błędy. Jednak programowanie wsparte testami zmniejsza szanse, że zarówno kod i testy są niskiej jakości. Często wprowadzenie poprawek w testach, daje dobry wynik.
4. TDD pomaga w programowaniu złożonych problemów. Dzięki testom analizujesz mniejsze fragmenty planowanej funkcjonalności, co automatycznie rozwiązuje skomplikowane problemy i szybciej posuwa proces tworzenia do przodu.
5. Testy jednostkowe umożliwiają lepsze zrozumienie projektowanego kodu. Zamiast jedynie kodowania określonych funkcjonalności, rozważasz projekt globalnie, koncentrując się na poszczególnych warunkach i oczekiwanych wynikach.
6. Testy jednostkowe dają natychmiastowe wsparcie w postaci wizualnej. Wszyscy lubią to uczucie, gdy wiesz, że wszystko działa poprawnie. To bardzo satysfakcjonujące. Poza tym, o wiele łatwiejsze jest naprawienie błędu, gdy dostajesz dokładną przyczynę jego wystąpienia.
7. Wbrew powszechnej opinii pisanie testów wcale nie wymaga dwukrotnie większej ilości kodu, ani nie zwalnia tempa tworzenia aplikacji. Wręcz przeciwnie, taki kod powstaje szybciej i jest mniej zawodny w porównaniu do zwykłego kodu. Napisane testy w większości przypadków są proste, jeśli nie banalne, co nie sprawia trudności w ich tworzeniu. Przekonasz się w momencie, w którym spróbujesz.
8. Myślę, że powiedział to Fowler:
   

   „Niedoskonałe testy, uruchamiane często są o wiele lepsze niż doskonałe testy, których nigdy nie napiszesz”.

   Osobiście odbieram to jako pozwolenie na pisanie testów tam, gdzie to najbardziej użyteczne, nawet jeśli pozostałe fragmenty mojego projektu nie mają wystarczającego pokrycia testami.

9. Dobre testy jednostkowe ułatwiają dokumentowanie kodu i dokładniejsze określenie, jak dany fragment rzeczywiście działa.
10. Test jednostkowe pomagają w ponownym użyciu kodu. Przenieś zarówno kod, jak i testy do nowego projektu. Dokonaj niezbędnych zmian kodu, aż ten znowu przejdzie wszystkie testy.

To tylko kilka z głównych przykładów sugerujących używanie testów jednostkowych. Sami zdecydujecie, czy takie postępowanie jest dla Was warte zachodu i niesie realne korzyści.

Oryginalny tekst pochodzi ze StackOverflow, gdzie dokładniej opisano koncepcje stosowania testów jednostkowych.