Battle for Agility

Akcent Agile na JDD 07

October 28th, 2007 Marcin Niebudek

Piątek spędziłem na Java Developers Day 2007. Dlaczego piszę tutaj o konferencji Java? W zeszłym roku agile było praktycznie w każdym wystąpieniu. Wszystkie produkty, praktyki, frameworki były agile. W tym roku coś się zmieniło… terminem agile nie wiało już z każdej prezentacji, co w sumie jest nawet lepsze, bo przywykliśmy do zbytnich nadużyć w kwestii stosowania agile wszędzie gdzie się tylko da.

Ale nie myślcie, że agile zniknęło z JDD. Także i tegoroczna edycja miała swój akcent w postaci wystąpienia Jakuba Dziwisza na temat “Test Driven Development w Java”. Wykład powinien być niedługo dostępny w wersji wideo na stronach organizatora konferencji, a na blogu Jakuba powinien się pojawić artykuł uzupełniający samą prezentację. Zaczęło się nieźle… Jakub przekonywał o zaletach TDD w tworzeniu oprogramowania, z czym generalnie się zgadzam. Były założenia TDD, trochę o trybie red - green - refactor, później prosty test, który nie przechodził ale wyznaczył funkcjonalność, implementacja (test przeszedł - byliśmy w green), wreszcie przyszedł czas na “refactor”.

Niestety etap refaktoryzacji zaprezentowany podczas wykładu był dla mnie nieco kontrowersyjny. Mianowicie za jednym zamachem uległa zmianie implementacja testowanej klasy i bez uruchomienia testów od razu uległa zmianie także implementacja samego testu. Być może nie było to zamierzone a jedynie podyktowane ograniczeniami czasowymi samej prezentacji, ale chciałbym podkreślić, że w TDD właśnie po to najpierw piszemy test, żeby później w trakcie refaktoryzacji móc na nim polegać zmieniając kod. Jeśli programista zacznie jednocześnie zmieniać kod testowany i kod testujący to jaką ma pewność czy zielony pasek nadal wskazuje, że kod działa, a nie że właśnie dostosował test do tego, żeby przechodził z nowym kodem? A co jeśli po takich jednoczesnych zmianach test nie przejdzie? Czy to oznacza że źle zrefaktoryzowaliśmy kod, czy może nie wyszła nam modyfikacja testu? Test ma łapać błędy powstałe podczas refaktoryzacji. Dopiero później przychodzi czas na ew. refaktoryzację samego kodu testów. Z reszta Jakub wspomniał o tym, że dobrze napisane testy nie powinny tak często wymagać zmiany, kiedy tylko refaktoryzujemy kod aplikacji.

Chciałbym się także odnieść do pytania, które padło z sali. Mianowicie “Do czego TDD się nie nadaje?”. Odpowiedzią było, że “nie nadaje się do utrzymania oprogramowania”. Z drugiej strony Jakub stwierdził, że nie wyobraża sobie napisania linijki kodu produkcyjnego bez wcześniejszego napisania testów. Ani jedna, ani druga odpowiedź nie do końca mnie satysfakcjonuje.

To jest generalnie dobre pytanie jeśli chodzi o agile, bo będąc entuzjastą jakiejś konkretnej praktyki lub wszystkiego co agile, dość łatwo mówi się o tym jakie to wszystko jest piękne, ale pamiętamy formułę “there is no silver bullet” prawda?

Akurat według mnie TDD doskonale nadaje się do utrzymania oprogramowania. Nie mówię tu bynajmniej o rozpoczynaniu krucjaty w pisaniu testów do wielkiego istniejącego systemu, który takich testów nie posiada. Byłoby to niewiarygodnie męczące i praktycznie nieuzasadnione jeśli chodzi o koszty. Ale jestem zdania, że w takim wypadku doraźne aplikowanie TDD do napotkanych błędów w tego typu kodzie jest bardzo dobrą praktyką.

Załóżmy, że zostaje zgłoszony błąd w utrzymywanym przez nas oprogramowaniu. Co należy zrobić?

Najpierw piszemy test, który reprezentuje oczekiwane przez nas prawidłowe działanie aplikacji (jesteśmy w fazie RED, test nie przejdzie, bo przecież mamy błąd w aplikacji).
Naprawiamy błąd. A skąd wiemy, że go naprawiliśmy? Bo przeszedł test, które wcześniej napisaliśmy. Jesteśmy w GREEN.
Skoro mamy poprawkę i test, który przechodzi, to czas na ew. REFACTOR. Wiemy, że mamy test, który odpowie czy nie zepsuliśmy poprawki.

Oczywiście w przypadku systemów, które nie posiadały wcześniej testów, faza 2 i 3 są trudniejsze, bo nie wiemy czy poprawka i refaktoryzacja nie wpłynęły negatywnie na inne części systemu na które nie mamy testów, ale cóż. Jeśli znajdziemy inny błąd to wracamy do kroku 1. W ten sposób doraźnie reagując budujemy powoli bazę testów dla systemu, który mogliśmy dostać w spadku. Przy okazji pisania testów uczymy się także samego systemu, a napisane w tym momencie testy zabezpieczą nas przed powrotem tego samego błędu w kolejnym wydaniu oprogramowania.

Czy w takim razie rozpoczynając nowy projekt można zastosować TDD wszędzie i nie powstanie ani linijka kodu bez testów, które najpierw nie przechodziły? Niestety nie zawsze jest to możliwe. Wg. mnie nie warto pisać testów jednostkowych dla klas GUI w aplikacjach typu desktop. Ciężkie jest także testowanie w ten sposób kodu widoków w aplikacjach webowych. Oczywiście to nie znaczy, że nie należy automatyzować testów tego typu elementów. Chodzi tylko o to, że są to elementy, które raczej nadają się do testów funkcjonalnych, najlepiej “nagranych” przy pomocy specjalnego oprogramowania przez testerów, a nie przez samych developerów i przynajmniej w moim przypadku nie bardzo sprawdzało się tutaj TDD w swojej czystej formie.

TDD to jednak jedna z bardziej interesujących praktyk agile, więc na pewno jeszcze do tego tematu wrócę.