Dziś opowiem Ci historię transformacji jakości mojej pracy. Przez wdrożenie TDD w mojej codziennej pracy programisty, jakość mojego kodu wzrosła, poziom stresu spadł, wraz z ilością wracających do mnie błędów.
Na początku mojej przygody z programowaniem wszystko testowałem ręcznie. Trwało to wieki, każdy nowy formularz, nowa strona. Wyszukiwarka, sortowanie, logowanie. Była tego cała masa, do każdej z tych funkcjonalności trzeba było wyklikać dane testowe. Coś zmieniłem, poprawiłem błąd? No to jeszcze raz, test całej ścieżki. Żmudna, ręczna robota.
To i tak nie rozwiązywało istoty problemu — błędy (goście od Quality Assurance nazywają je defektami) były. Najgorsze było to testowanie w kółko tego samego. Każda zmiana była obarczona ryzykiem, że coś się wywali. I to w zupełnie innym miejscu! Stresujące, prawda?
Wtedy już nawet wiedziałem co to testy automatyczne. Jak w Django napisać kilka testów, tylko... wciąż nie widziałem w tym większego sensu. Przecież pisze proste aplikacje, poza logowaniem i założeniem konta niewiele tam jest. Po co to testować automatycznie, szkoda czasu. Więcej zrobię bez tego. Brzmi znajomo?
I tak sobie żyłem w stresie, programując powoli. Myślę, że spora część tych złych nawyków pochodziła od moich korzeni na frontendzie — wtedy nikt nie testował JS na FE.
Miałem to szczęście, że bardziej doświadczony kolega z pracy mnie cisnął o pisanie testów. Nawet nie tyle samo pisanie testów tylko całą metodologię TDD. Oczywiście na samym początku pisałem testy po napisaniu swojego kodu... w ramach nauki. Natychmiast zauważyłem poprawę jakości pracy. Już nie musiałem po każdej zmianie klikać po całym serwisie. Co było obtestowane, było "bezpieczne". Odpalałem jedną komendę, piłem kawkę, patrząc na pasek postępu. Przeszło? Cudnie. Nie było to jeszcze jednak cudowne rozwiązanie wszystkich moich problemów. Testy pisane "z dołu" z natury są... trudne. Kod, który testujesz, często nie jest odpowiednio modularny. Funkcje bywają długie, pojawia się spaghetti. Dodatkowo często jakieś efekty uboczne, które test zapewne zignoruje.
Wchodzi TDD.
Czym jest TDD? Wielkim skrócie, piszesz test, potem dopiero kod, który ma go przejść. Jak to wygląda w praktyce? Weźmy sobie taki prosty formularz logowania: przyjmuje parametry e-mail i hasło. Test do tego powinien: zalogować użytkownika ze znanym adresem e-mail i hasłem. Logowanie jest wykonywane przez formularz, który wysyła dane na konkretny end point. Test powinien wysłać dane postem na ten sam end point i sprawdzić odpowiedz HTTP - 200 OK czy coś innego. Dodatkowo może sprawdzić, czy odpowiedź zawiera wszystkie oczekiwane dane: imię, nazwisko, login, itp. Test powinien też sprawdzać, czy użytkownik jest aktywny oraz, czy w ogóle istnieje. O sprawdzeniu poprawności adresu e-mail już nawet nie ma co pisać. Jak widać prosty test, który będzie miał max. 30 linii, sprawdza masę warunków. To jest naprawdę krok milowy. Napisanie takiego testu zajmie ~ 30 min. I teraz można sobie środowisko ustawić, żeby testy były uruchamiane przy każdym git push. Oczywiście, można je też uruchamiać ręcznie. Prawda, że fajne?
Odkąd zacząłem stosować TDD. mój programistyczny świat się zmienił. Jakość pisanego kodu wzrosła zdecydowanie. Testy jednostkowe same z siebie to wymuszają — zaczynasz pisać krótkie funkcje, które są łatwe w testowaniu. Oczywiście zdarza się większy test, integracyjny żeby sprawdzić, jak to wszystko gra razem, ale... ten test już nie musi być tak szczegółowy, bo poszczególne kroki sprawdziły testy jednostkowe.
Poziom stresu się zdecydowanie zmniejszył, zaufanie do kodu wzrosło, do własnych umiejętności też. Ilość błędów na produkcji oczywiście też spadła.
Ciężko policzyć, ile razy testy uratowały mi tyłek.
Napisałem kiedyś duży system do deploymentu mikro serwisów na AWS Lambda. System ogarniał wiele kont AWS, lambd było kilkadziesiąt. Po napisaniu generalnie sobie leżał i po prostu wykonywał swoją robotę. Co kilka miesięcy, bliżej roku, trzeba było do systemu wrócić i coś do niego dopisać, poprawić. Nie wyobrażam sobie, jak miałbym to zrobić bez testów. Przecież po takiej przerwie ja niewiele z tego pamiętam. Co więcej, ten system dotyka bezpośrednio produkcji, jak cos schrzanię, będzie duży ból. Tak, miałem tam testy. Dużo testów. Również na funkcjach, które gadały bezpośrednio z AWS. Wspaniały spadochron, dzięki któremu wprowadzanie zmian bolało dużo mniej.
A Ty? Jak testujesz swój kod? Piszesz testy, skrypty, które coś testują, czy może testujesz ręcznie? Daj znać! Zapraszam do zadawania pytań przez formularz kontaktowy. Pamiętaj, że jeśli potrzebujesz wsparcia, możesz napisać do mnie - pomogę.
Zapraszam do dołączenia do naszej społeczności na https://pymasters.pl/spolecznosc, gdzie możesz rozwijać swoje umiejętności programistyczne w przyjaznej atmosferze. Czekamy na Ciebie, aby razem zgłębiać tajniki programowania i dzielić się wiedzą - również o testach!
Spodobał Ci się post?
Podziel się nim!
Masz uwagi do posta, chcesz porozmawiać, szukasz pomocy z Pythonem i Django? Napisz do mnie!