7 mitów na temat TDD głoszonych przez tych, którzy go nie używają

Szymon Pruszyński

Programiści, którzy nie używają Test-Driven Development mają najczęściej swoją własną wizję, jak wygląda praca tych, którzy TDD stosują i jakie mają problemy.

W tym tekście 7 najczęstszych mitów rozwiewa „nawrócony” na TDD Tomasz Jerzak, który uczestniczył w serii naszych szkoleń.

tdd-joke

1. „Testy w żaden sposób nie wpływają na architekturę kodu”

Przed stworzeniem nowego kodu planuję test, który będzie wykorzystywał i weryfikował nową funkcjonalność. Pisząc najpierw test mam możliwość sprawdzenia, w jaki sposób będzie wyglądała praca np. z nową metodą. Czy znajduje się ona w prawidłowym miejscu, czy jej użycie w taki, a nie inny sposób ma sens? Test, który powstaje przed implementacją kodu wymusza na mnie bardzo dokładne przemyślenie projektu. W TDD architektura pojawia się sama z siebie, musimy tylko zadbać o proste i skalowalne fundamenty.

Prawdziwa genialność tkwi w tym, że w efekcie twój program robi dokładnie to, co chcesz. Architektura jest z reguły mniejsza, obiekty robią dokładnie to, co powinny robić. To esencja designu! Twój kod jest precyzyjny, elegancki i pozbawiony zbędnych ozdobników. Lubię metaforę jednego z francuskich programistów, który twierdzi, że „kod tworzony w TDD nie jest pozłacany, ale wykuty w złocie”!

2. „Testy dają iluzoryczne poczucie bezpieczeństwa”

Jeśli rozbudowuję system z podejściem TDD to moje poczucie bezpieczeństwa nie jest może stuprocentowe, ale nie jest na pewno iluzoryczne! To test powoduje powstanie funkcjonalności i to test pozwala na refaktoryzację kodu. Jeżeli nowa zmiana wprowadzona w kodzie spowodowała, że jeden lub więcej testów przestało działać to znaczy, że ta zmiana najprawdopodobniej wygenerowała błąd. Na każdym etapie pracy możemy więc zweryfikować, czy po modyfikacji test wypadnie pomyślnie i uzyskamy oczekiwany rezultat, czy nie. Jeśli test się nie powiedzie – pracujemy dalej nad poprawieniem danej funkcjonalności.

Korzyść płynąca ze stosowania TDD, jaką jest czystszy i zawierający mniej błędów finalny kod, została udowodniona na przykładzie wielu projektów, ale na bezpieczeństwo wpływa sama stosowana metoda. Przy refaktoryzacji dzięki temu, że testy pokrywają wszystkie istotne stany aplikacji i obszary kodu, możemy czuć się naprawdę bezpieczni. Kontrola jakości nie jest nowym procesem, ale jest ciągła.

3. „Praca w TDD wymaga dużo więcej czasu”

Zaplanowanie i napisanie testu zajmuje czas, to oczywiste. Jednak czas realizacji funkcjonalności z pomocą TDD nie może być rozpatrywany w kontekście tylko czasu tworzenia kodu, ale całego cyklu dostarczenia danej funkcjonalności. Przykład: rozbudowuję aplikację MVC poprzez implementację nowych metod w repozytorium i kontrolerze. Dostarczam kod, który jest gotowy do wykorzystania bez konieczności każdorazowego sprawdzania w przeglądarce. Na końcu dodaję widoki.

W podejściu bez TDD po każdorazowym dodaniu metody, np. do kontrolera, odpalałbym przeglądarkę, klikał, potem może debugował, i tak w kółko. Natomiast stosując TDD nie tylko nie robię tego, ale też dodatkowo mam gotowy test, który w przyszłości pozwoli kontrolować dalszą rozbudowę o nowe funkcjonalności lub będzie wspierać prace związane z refaktoryzacją i optymalizacją. Z podejściem TDD czas wcale się nie wydłuży, a wręcz przeciwnie – dzięki automatycznemu testowaniu kodu oszczędzam czas, no i oczywiście tworzę lepszy kod.

4. „TDD nie ma sensu, jeśli reszta zespołu tak nie pracuje”

TDD to sprawdzona metoda działania. Ma sens, nawet jeśli inni programiści w zespole jej nie wykorzystują. TDD to nie jest dążenie do stuprocentowego pokrycia kodu testami, ale sposób pracy, podejście do wytwarzania oprogramowania każdego dnia, które staje się nowym, lepszym nawykiem.

To trochę tak jak z pozytywnym podejściem. Nie da się go narzucić wszystkim dookoła, ale jeśli sami staramy się utrzymywać dobry nastrój, to na pewno poczujemy się lepiej. A wtedy może i inni przekonają się do naszego podejścia? Myślisz o spróbowaniu TDD? Zrób to śmiało. Przecież deweloperzy nigdy nie pytali nikogo, czy mogą używać debugowania. Dlaczego mieliby prosić o prawo do używania TDD w pracy?

5. „Refaktoring zawsze można zrobić później”

Można zrobić później, serio? Często odkładamy refaktoring, może nawet z przekonaniem, że na pewno znajdziemy na niego czas. Jednak tak się nie dzieje. Pojawiają się nowe funkcjonalności do napisania, defekty do naprawienia, nieprzewidziane problemy… i w rezultacie nigdy tego nie robimy.

W TDD nie odkładam refaktoringu na później, ale mam na niego czas w ramach pracy. Faza związana z refaktoryzacją jest nieodłącznym elementem całego cyklu TDD. Nie omijam tego etapu, tylko co chwila poprawiam kod choć odrobinę.

A jeśli chcę dokonać w pewnym momencie znacznie większej i dalej idącej refaktoryzacji, to jest ona wtedy prostsza. Mając testy zmniejszam ryzyko, że moje zmiany uszkodzą istniejącą funkcjonalność.

6. „W TDD chodzi głównie o testowanie”

Pisanie testów jednostkowych pozwala w łatwy sposób uzyskać sygnały ostrzegawcze o wielu niepokojących aspektach, np. zbyt mocnych powiązaniach między częściami systemu. Ale to nie wszystko! Testy jednostkowe pełnią też funkcję dokumentacji. Chcesz skorzystać z mojej klasy, ale nie wiesz jak? Popatrz na testy.

TDD to ciągłe dbanie o jakość, na każdym etapie projektu. Dokumentacja nie jest nowym procesem, ale elementem procesu. Testy jako dokumentacja są zawsze aktualne i jednoznaczne, w przeciwieństwie do dokumentacji papierowej.

7. „W wielu przypadkach pisanie testów nie ma sensu”

Im więcej testów piszemy, tym łatwiejsze staje się pisanie kolejnych. Testy, które początkowo wydają się nam zbyt kosztowne do napisania lub bezsensowne, po pewnym czasie powstają zupełnie naturalnie.

TDD pozwala szybko i sprawnie zweryfikować większość pomysłów i koncepcji związanych z dalszym rozwojem oprogramowania. Posiadanie aplikacji budowanej w taki sposób pozwala uzyskać bogaty „setup” do eksperymentów. W połączeniu z językiem obiektowym taki setup daje bardzo duże możliwości do improwizacji, a często też do studzenia emocji i zejścia na ziemię.

 

Czy już cię przekonaliśmy, że warto się zainteresować TDD? A może tak, jak nasz klient Tomasz, chcesz spróbować najpierw z nami? Odezwij się do Szymona i zaproś nas do siebie!

comments powered by Disqus