Czasami (czasami często) słyszę, że:
…ktoś nie napisał testu jednostkowego bo nie miał na to czasu.
Gdy to słyszę to aż bolą mnie zęby. Jak można nie mieć czasu na sprawdzenie, czy nasz kod działa poprawnie? Wtedy zawsze staram się wyjaśnić, że:
… ja nie mam czasu nie pisać testów jednostkowych.
Nie mam czasu marnować czas na uruchomienie całego środowiska i wykonywania wszystkich kliknięć w aplikacji, aby sprawdzić, czy przed chwilą napisany kawałek kodu działa zgodnie z moimi oczekiwaniami.
W przeszłości
Załóżmy, że w przeszłości nie miałeś wystarczająco dużo czasu na napisanie testu jednostkowego, aby sprawdzić, czy aplikacja działa poprawnie. Przeklikałeś aplikację i z większym lub mniejszym strachem powiedziałeś, że działa.
W przyszłości
Załóżmy teraz, że w przyszłości, zmieniłeś kod w taki sposób, że obawiasz się, czy kilka poprzednich funkcjonalności nadal działa poprawnie. Musisz teraz przeklikać wszystkie te przypadki użycia w ramach tych newralgicznych funkcjonalności od nowa.
A gdybyś
A gdybyś poświęcił czas na napisanie testu jednostkowego, zamiast poświęcić go na klikanie, to w przyszłości nie poświęciłbyś ani sekundy na ponowne klikanie — testy jednostkowe sprawdziłby ten kod za ciebie. Nie strachu o błędy regresyjne.
Tak zaoszczędzony czas pozwoli ci na napisanie więcej nowych funkcjonalności z testami jednostkowymi, na które nigdy nie miałeś czasu, bo musiałeś klikać po aplikacji.
Każde takie manualne przetestowanie aplikacji zaraz po najbliższej zmianie kodu jest nic niewarte. Po każdej zmianie kodu czas poświęcony na manualne przetestowanie wyrzucany jest do kosza. Czas, który włożyliśmy w manualne testowanie, nigdy już w przyszłości nam się nie zwróci. Czas ten jest czasem bezpowrotnie zmarnowanym.
Więc jeśli mamy mało czasu (a zawsze mamy go mało) to oszczędzajmy go, pisząc test jednostkowy, zamiast trwonić go, robiąc testy manualne.
Napisanie testu jednostkowego jest o wiele szybsze od wielokrotnego przeklikania aplikacji na nowo po każdej zmianie. Czas włożony w stworzenie testu jednostkowego, będzie nam się zawsze zwracał, przez cały czas trwania projektu.
Zamiast szastać czasem na prawo i lewo na klikanie po aplikacji w celu jej przetestowania, ten sam czas wykorzystaj na napisanie testu jednostkowego. Jeśli poświęcisz tyle samo czasu na pisanie testu jednostkowego — ile potrzebowałbyś na uruchomienie aplikacji i wykonanie scenariusza testowego manualnie — już zaoszczędziłeś czas. Pisząc test jednostkowy, będziesz mógł wykonywać ten sam test wiele razy w przyszłości, nie poświęcając na niego ani sekundy.
Co zarząd na to
Nie wszędzie, ale może tak być, że zarząd się ani nie ucieszy, ani ucieszy, gdy będziesz się chwalić, że przetestowałeś swój kod testami jednostkowymi. Zarząd może kompletnie nie kumać, o co ci chodzi.
Natomiast jeśli powiesz, że teraz możesz pisać więcej funkcjonalności w tym samym czasie z mniejszą liczbą błędów, to może tak być, że Cię przynajmniej pochwalą.
Inne zalety
No i oczywiście jest WIELE innych zalet pisania testów jednostkowych takich jak na przykład wymuszenie na programiście pisania kodu obiektowego lub odseparowanie od siebie warstw aplikacji poprzez abstrakcje — ale nie o tym tutaj w tym poście… W tym poście opisuje sytuację, gdy nie ma czasu na nic, więc na obiektowy kod też nie byłoby czasu ma czasu :).
Teo Vincent 