"Jak być lepszym programistą?", czyli testowanie oprogramowania dla zielonych

Wstęp i przestroga, czyli kim powinieneś być, żeby zrozumieć dalszy bełkot...

Nie ukrywam - to NIE jest artykuł dla początkujących. Zakładam, że umiesz już programować. Poziom nie jest ważny, jeśli wiesz czym jest pętla for i stworzyłeś swój własny kalkulator to nie masz się czego bać.

Dlaczego zdecydowałem się to napisać?

Wśród wielu moich znajomych jest wiele osób, ktore widzą co to kodowanie, piszą swój własny kod, ale są strasznie sfrustrowane efektami.

"Olo, dlaczego mi to nie działa?!"

"Zmieniam jedną rzecz w kodzie a IDE krzyczy mi dziesięcioma błądami w konsoli, jak można mieć tyle cierpliwości, żeby kodzić na codzień w pracy?"

Takie rzeczy słyszę relatywnie często, szczególnie od osób, które coś już wiedzą, ale brakuje im jeszcze pewnego sposobu pracy, który pozwoli na 'płynne forkflow'.
Pomyślałem, że warto stworzyć post, który pomoże każdemu, kto takiej pomocy szuka, nie tylko temu, kto mnie o nią poprosi...

Na początek jedna bardzo ważna rzecz.

Jeżeli myślałeś, że to będzie coś lekkiego, czego będzie można się nauczyć dla relaksu w przerwie do pisania kodu, mam dla Ciebie złą wiadomość...
Testowanie jest jak programowanie - nie da się do nauczyć od A do Z

Niestety - jedno w porywach do pięciu piwerek albo parę kubków kawy nie wystarczy. Kilka artykułów nie zrobią z Ciebie testera, ale przynajmniej poznasz podstawy i filozofię testowania. To będzie tylko (albo aż) pierwszy krok, ale jeśli pamiętasz swoje programistyczne początki, to pewnie zdajesz sobie sprawę z tego, że najtrudniej było wystartować, potem było z górki.

Dlaczego warto testować kod?

Powodów do tego, żeby testować kod jest wiele. Nie wdrażając się na razie w szczegóły czym są testy, bo ich rodzajów także jest wiele, mogę odpowiedzieć ogólnie, a gdy zaczniesz testować kod sam zobaczysz jak bardzo pomogają Ci testy.

1. Jako programista chcesz pisać kod który działa, prawda?

Testy (o ile dobrze napisane) dają Ci jasną informację, czy kod, który napisałeś faktycznie działa tak, jak założyłeś. Jeśli coś się zepsuje, to będziesz dokładnie wiedział co się zepsuło, w którym jest miejscu, i jak powinno działać.

2. Wolisz rozwiązać 5 małych problemów, czy jeden duży?

Podejście do programowanie w sposób oparty o testy znacznie ułatwia 'rozbijanie' problemów na mniejsze i o wiele prostsze - dzięki temu, gdy napotkasz jakąś pozornie straszną i wielką kobyłę podejdziesz do niej bardziej systematyczne i metodycznie, zamiast siłować się z nią godzinami.

3. Dlaczego to nie działa?!

Testując kod już nigdy nie zadasz tego pytania - jeśli coś się wysypie, będziesz wiedział co dokladnie poszło nie tak i gdzie musisz poszperać, żeby to naprawić.

4. Wreszcie napiszesz kod, któremu zaufasz.

Miałeś kiedyś tak, że pomimo tego, że to Ty pisałeś kod, nie darzyłeś go wielkim zaufaniem?

To było dawno dawno temu, jedyne co pamiętam, to że przy pisaniu kodu piłem bardzo dobre piwesio. Gdybym miał sobie za ten kod dać rękę uciąć, to mógłbym tej ręki teraz nie mieć...

Testy nie wybacząją - albo 'przejdą', albo nie. Jeśli przetestujesz kod poprawnie i konsola oznajmi, że wszystkie testy dają Ci zielone światło, to możesz być w miarę pewny, że skoro poświęciłeś w przeszłości czas na przetestowanie kawałka kodu, to jest on solidnie napisany i możesz mu ufać.

5. Zmieniłem tylko jedną małą rzecz, dlaczego wszystko się wywaliło?

Każdy, kto tworzył odrobinę bardziej skomplikowany projekt niż kalkulator wie, że zmiana czegokolwiek w już istniejącym kodzie to stąpanie po cienkim i kruchym lodzie...

Nie wiem jak Ty, ale Ja naprawiając nieprzetestowany kod czuję się jakbym sprzątał mieszkanie w brudnych butach - co z tego, że jeden kawałek odpicowałem na błysk, skoro tuż obok znów naniosłem brud?

Z testami u boku rzecz ma się zupełnie inaczej! Teraz masz jasną informację - kod dalej działa, bo wszystkie testy dalej są zielone, albo dostajesz jasną informację, co i gdzie się zepsuło, dzięki czemu szybko spowrotem to naprawisz.

6. Mordo... No nie wiem... To chyba jest dla mnie za trudne.

I tu dochodzimy do najważniejszej zalety. Jeśli kiedyś chciałeś coś zrobić, ale uznałeś to za zbyt trudne - testy mogą Ci pomóc. Wszystkie powody, które napisałem wcześniej łączą się w jedną najważniejszą rzecz, która jest dla testów unikalna.

Zamiast myśleć w sposób:

"To zbyt trudne, raczej sobie z tym nie poradzę"
~ Mariusz, stażysta-programista

Zaczniesz myśleć w sposób:

"To trudne, ale lubię wyzwania. Jeśli rozwiążę ten mniejszy problem i test przejdzie, będę znacznie bliżej rozwiązania."
~ Stachu, koder-tester.

Wiem co możesz sobie myśleć...

Dlaczego marnować czas na pisanie dodatkowego kodu? I tak siedzę na tym długo, a mogę w tym czasie zakodować o wiele więcej!

Każdy na początku zadaje to pytanie, i bardzo dobrze - nikt nie chce robić czegoś, co tylko niepotrzebnie zajmuje czas. Szczgólnie na początku testowanie może być kulą u nogi i trwać dłużej niż pisanie samego kodu.
Jednak tutaj sprawa ma się troszczkę inaczej - programowanie na dłuższą metę to nie tylko pisanie kodu, ale w znaczej większości czytanie i poprawianie tego, co już zrobiłeś. Dlatego testy możesz potraktować jako lokatę na przyszłość:

Napiszę ten kod wolniej, ale solidniej - dzięki czemu w przyszłości łatwiej będzie mi go utrzymać, bo nie będzie posklejany na taśmę i gumę do żucia.

Dobra, dosyć tego bajdurzenia! Możesz mi w końcu powiedzieć czym są te testy?

No właśnie... Będę szczery: ten post to tylko clickbait - jeśli chcesz, może być częścią czegoś większego, czegoś co może dopiero powstać.

Jeśli Ci się spodobało, masz jakieś pytania, sugestie a może znalazłeś błąd, lub uważasz, że piszę bzdury - napisz w komentarzu, ja też dopiero zaczynam, więc mogę się mylić.

Nie mniej pozdrawiam i gratuluję dotarcia do końca. :)

To pisałem ja - olo dwapięćpięćdwa