Jeśli myślisz, że testy dają gwarancję bezbłędnej refaktoryzacji, to trochę masz rację, ale też trochę nie masz 🙂 Im lepsza baza testów, tym szansa na wykrycie regresji będzie wyższa. Nie gwarantuje to jednak, że w każdym przypadku kod będzie działał zgodnie z pierwotnymi wytycznymi. Refaktoryzacja polega na zmianie implementacji bez zmian w funkcjonowaniu aplikacji i nie zawsze jest łatwym zadaniem. Sytuacja może być tym trudniejsza, im mniej znasz wymagania biznesowe. Kiedy nie bierzesz udziału w procesie planowania i podejmowania decyzji, znasz tylko to, co zostało spisane w formie testów lub kodu.

Słyszałam ostatnio świetną historię, którą opowiadałam już podczas mojej prezentacji o testach. Otóż mój znajomy, który jest konsultantem specjalizującym się w code review i refaktoryzacji, dostał zlecenie uporządkowania kodu w pewnym projekcie. Ku jego zdziwieniu, w projekcie nie było żadnych testów. Żadnych! Postanowił więc zacząć od pokrycia kodu testami, żeby potem bez lęku refaktoryzować. Kiedy skończył, firma zlecająca wrzuciła kod prosto na produkcję i … myślisz, że się udało? Niestety nie, produkcja padła i potrzebny był rollback. Jak widzisz, nawet najlepsze testy pisane przez kogoś, kto nie zna biznesu mogą być niewiele warte. Dlatego pisz testy wraz z kodem. I nie bój się refaktoryzacji, większość firm nie wrzuca kodu prosto na produkcję 😉

Nie znam wielu osób, które pałają miłością do pisania testów. Często spychamy to na ostatnią chwilę, albo „zapominamy”. Skutkiem może być historia jak w poprzednim akapicie. Zapewnianie dobrej jakości oprogramowania jest jednak naszym obowiązkiem, ponieważ jesteśmy solidnymi rzemieślnikami. Dbamy o to, żeby kod działał nie tylko zaraz po wyjściu spod naszych palców, ale również za klika dni i kilka lat. W tym temacie jedną z najbardziej niezmordowanych osób jest Marcin Kubala. Miałam okazję z nim pracować przy projekcie e-commerce. Możesz posłuchać, co Marcin ma do powiedzenia na temat testów w naszej Rozmowie o Jakości.