Praca bez testów automatycznych

Wyobraź sobie następującą sytuację. Janusz uważa się za profesjonalnego programistę, przez co testuje swoje rozwiązanie przed wrzuceniem kodu do repozytorium, jednak testy wykonuje manualnie. Dostał on nowe zadanie do wykonania. Z uśmiechem na twarzy napisał piękny i czysty kod. Teraz chce sprawdzić, jak on działa. Uruchamia więc system, loguje się, wybiera z menu interesujący go moduł, następnie wprowadza dane, po czym okazuje się, że pojawił się błąd. Janusz poprawia więc kod i ponawia próbę. Tym razem problemem są dane, których nie może wykorzystać ponownie. Na twarzy Janusza pojawia się grymas, ponieważ musi teraz poświęcić czas, aby je wygenerować. Po kilku minutach klikania po różnych modułach zaczyna pojawiać się u niego frustracja. Kawa, na którą Janusz miał się udać po wykonaniu zadania będzie zbędna. Gdy w końcu udało mu się przygotować wszystko, co potrzeba, sprawdza swoją funkcjonalność. Na ekranie widzi błąd. Poprawia kod i proces zaczyna się na nowo. Horror. Czas nieubłaganie brnie do przodu. Nerwy przebijają się przez tamę, jego stoickiego spokoju zalewając go negatywnymi emocjami. Po siódmej porażce siarczyście klnie pod nosem. Musi wyjść na papierosa, by się uspokoić. Pali od niedawna, biedak nie potrafił w inny sposób poradzić sobie z szarpiącymi go nerwami. W pięknym ogrodzie jego umysłu niczym chwasty zaczynają pojawiać się myśli o zrzuceniu odpowiedzialności za jakość swojej pracy na testera manualnego.

Mija miesiąc, Janusz ma już dość i postanawia porzucić sprawdzanie jakości własnej pracy. Bez testowania, wrzuca zmiany do repozytorium. Z uśmiechem na twarzy przechodzi do tworzenia kolejnych zadań. Czuje złudną ulgę. Wydaje mu się, że niesamowicie przyśpieszył.
Niestety jego pozorne szczęście trwało tylko chwilę. Gdy pewny siebie był w połowie tworzenia nowego modułu, przyszedł czas zapłaty za dług, który niewątpliwie zaciągnął. Tester zaczął zgłaszać błędy do kodu, od którego rozpoczął swoje radosne kodowanie bez sprawdzania jakości. Janusz wrócił do poprzedniego zadania. Poprawa błędu okazała się prosta. Jednak przez to, że pętla zwrotna informacji o problemie występującym w kodzie wydłużyła się, poświęcił on dużo czasu na przypomnienie sobie, o co chodziło w danej funkcjonalności. Z dnia na dzień coraz więcej czasu poświęcał na analizę i poprawę błędów niż na tworzenie nowych funkcji systemu.

Tempo pracy zwolniło, było jeszcze gorzej niż podczas ręcznego sprawdzania kodu. Powrót do kontekstu poprzednich zadań zabierał Januszowi dużo czasu, co go frustrowało. Każdy zgłoszony błąd wpływał negatywnie na jego samopoczucie. Kiedyś czuł się profesjonalistą, teraz za każdym razem, gdy widział, zbliżającego się do jego biurka testera klął pod nosem. Stracił ten błysk w oku i zapał do pracy. Do pokonania negatywnych emocji nie wystarczały mu już papierosy. Co następnie, alkohol?

A mógł tego wszystkiego uniknąć, wystarczyło, żeby nauczył się pisać testy jednostkowe.

Ten wpis to fragment z mojej książki: