Wstęp
Wiele osób, które interesują się programowaniem i programuje aplikacje, po jakimś czasie natykają się na dość tajemnicze pojęcie TDD. Skrót ten oznacza "Programowanie napędzane testami" (ang. Test Driven Development). Zastanówmy się chwilę, czy użyłbyś urządzenie, które wygląda niebezpiecznie i nie zostało przez nikogo przetestowane? Tak samo jest z programowaniem. Czy jesteś w stanie udowodnić, że ten program działa i ręczysz za niego całą swoją reputacją? No nie za bardzo. Oczywiście spodziewasz się pewnego wyniku działań ciągu instrukcji, ale nigdy nie jesteś 100% pewny, że to właśnie tak zadziała. Dlatego też, w większych projektach ludzie stosują testy jako potwierdzenie działania swojego kawałka kodu.
Czym, według mnie, jest test?
Test w programowaniu, to założenie, że dany kawałek kodu lub część pewnej infrastruktury działa w oczekiwany sposób dokładnie jak to określił deweloper.
Jakie są rodzaje testów?
Rozróżniamy tak naprawdę kilka rodzajów testów w programowaniu:
- Testy jednostkowe(ang. Unit tests) - testujemy mały kawałek kodu w obrębie danej metody
- Testy integracyjne(ang. Integration tests) - testowane są różne części systemu ze sobą np. zapytania bazodanowe i generowanie na ich podstawie jakiś danych
- Testy akceptacyjne(ang. Acceptance tests) - testowane są tutaj określone funkcjonalności całej aplikacji
My zajmiemy się testami jednostkowymi, które są powiązane z TDD.
Czym jest TDD?
TDD, to sposób pisania aplikacji, gdzie zakładamy, że deweloper najpierw określa w teście co aplikacja ma zrobić, następnie sprawdza czy kod przechodzi test pomyślnie, pisze kod programu, uruchamia testy upewniając się, że przechodzi on początkowo napisane testy, refactoruje(poprawia kod nie zmieniając jego funkcjonalności) kod i na końcu powtarza ten proces od początku.
Poniżej przedstawiam wam jak wygląda ten cykl na obrazku
Dlaczego TDD jest trudne do realizacji?
Jeżeli programista chce użyć tych zasad, to według algorytmu, najpierw musi napisać test, a potem do niego napisać kod programu. No ale jak to, jak można testować coś czego jeszcze nie ma? No właśnie to jest problem dla osób zaczynające pisać używając TDD. Trzeba po prostu tworzyć szkielet klas podczas pisania testów i po kolei wypełniać wygenerowane metody. To nic, że klasy mają jakieś robocze nazwy, nazwać to wszystko możemy to trochę później. Z tego powodu, że ludzie mają problem z pisaniem testu, a potem kodu. Z tego też powodu niektórzy mają taki zwyczaj, że najpierw piszą kod, a potem piszą do niego test. Jest wiele dyskusji na ten temat czy można tak "Hakierować" pierwotne założenia tego sposobu programowania, ale jednak kluczowe jest tutaj zapewnienie 100% pokrycie sensownymi testami krytycznych części aplikacji.
Dokonywanie zmian w wielkim projekcie bez testów
W mojej niedługiej karierze jako programista zdążyłem spotkać się już z większym projektem (Nie moim xd), który był pisany kilka lat, przez wielu programistów, w super starej technologi flashowej i nie posiadał on ŻADNYCH testów jednostkowych. Posiadał on taki dług techniczny oraz wysokie ryzyko sypnięcia się programu, że jakakolwiek ingerencja w istniejący już kod, powodowała u mnie sporą frustrację. Oczywiście jak przekopałem się przez kod i nałożyłem swoje zmiany, to czułem tę stabilność, jednak to co się namęczyłem, to moje. Wychodzi z tego wniosek, że bez testów, programista boi się czegokolwiek zmieniać, bo jakakolwiek zmiana może totalnie zmienić działanie aplikacji.
Ale przecież testy to są marnowaniem czasu. Przez ten czas napisałbym połowę programu!!1!1!
Bardzo często występują takie wymówki u wielu programistów, że po co komu testowanie, "przecież działa, po co drążyć", albo "Te testy tak długo się wykonują, że nie warto". Testy jednostkowe w założeniach są krótkie i powinny wykonywać się w krótkim czasie. A to, że aplikacja się nie wysypała, to tylko szczęście programisty i założenie, że programista jest nieomylny (nie jest).
Jak żyć w projekcie bez testów?
W idealnym świecie, jak jest taka możliwość, to rozwiązanie jest jedno - pisanie testu do każdego kawałka funkcjonalności i modlenie się, że przy zmianach ten test będzie przechodził i nie wywali się coś innego. Tu jest niestety to ryzyko, że nie przetestujemy wystarczająco głęboko naszych metod jakie musimy zmienić. Jak uda nam się napisać w jakimś miejscu test, to warto takie miejsce od razu refactorować i zmniejszać dług techniczny takiej aplikacji. Oczywiście zakładając, że aplikacja będzie rozwijana, a nie tylko utrzymywana bez szansy na nowe wydanie.
A czy ty wykonujesz testy jednostkowe?
Kto zawsze pisze testy jednostkowe, to niech pierwszy rzuci kamieniem. Oczywiście, że nie zawsze kieruję się zasadami z TDD z różnych powodów. Jednym z nich jest taki, że zostałem np. rzucony do nowej technologii, gdzie nie znam odpowiednich bibliotek do testowania, bądź nie wiem jak ich używać. Innym z powodów, jest to że projekt jest naprawdę mały i napisałbym go z 10 razy w czasie pisania testów. Czasem po prostu zapominam o nich lub przestaję się nimi przejmować z jakiś powodów. Testy omijam głównie z powyższych powodów i w swoich mniejszych prywatnych projektach, co nie znaczy, że jest to zachowanie godne naśladowania. Po prostu ja sam czuję tu problem, który próbuję w sobie poprawiać, ale wiadomo jak jest.
Podsumowanie
Im wcześniej poznamy Test Driven Development, tym szybciej będziemy wstanie pisać kod, do którego nikt nie będzie bał się przysiadać i coś zmieniać. Nawet my sami nie mamy pewności co nasz kod robił tydzień po ostatnim dotykaniu danej funkcjonalności a co dopiero miesiąc później. Jestem świadom, że takie testy nie są łatwe do wdrożenia, szczególnie przy oryginalnych założenia, ale jednak liczba zalet znacząco przeważa trudności przy początkach.