Ochy i echy o GeeCON TDD -- polecam!

Wciąż nie mogę uwierzyć, jak bardzo pomysł 30-minutowego wystąpienia może być uczący! Organizatorzy GeeCON TDD mają głowę na karku -- 30 minut na prezentację to dokładnie tyle, ile należy poświęcić na przekazanie właściwej porcji wiedzy jako prelegent i utrzymać cierpliwość słuchaczy. Możnaby powiedzieć, że w ten oto sposób efektywnie “oderano” mi prawo do dywagacji i dowcipkowania na tematy różne podczas występiania. Gratuluję doskonałego pomysłu!

Dziękuję organizatorom również za zaproszenie do wystąpienia w roli prelegenta z tematem "Translating Requirements into Executable Software Specification with specs2".

Dziękuję organizatorom Łukaszowi, Adrianowi, Idzie, Adamowi za wspaniałą atmosferę podczas konferencji!

Slajdy dostępne są na http://blog.jaceklaskowski.pl/specs2-executable-software-specification-slides.

Kolejny raz skorzystałem z reveal.js, co polecam początkującym w branży wystąpień publicznych lub efektywnego przekazywania wiedzy - zamiast artykułu czy wpisu na blogu można użyć medium w postaci slajdów. Jeśli zastanawiasz się, jak zacząć w temacie - chociażby miało się skończyć wyłącznie na przygotowaniu slajdów - pisz. Chętnie pomogę.

GeeCON stał się marką i każda inicjatywa spod tego parasola to wydarzenie wielkiego formatu. Zaczęło się od konferencji stricte javowej, aby później stać się konferencją o tematach z branży programowania i zarządzania projektami, aby ostatni pomysł skoncentrować wokół testowania (bez przywiązywania go do konkretnego języka czy biblioteki). Tym razem owe 30 minut i tematyka sięgająca poza JVM pozwoliła mi na doświadczenie nowych doznań - ludzie jakby nowi i raczej w większości dużo młodsi (i raczej nie doświadczeniem).

Miło było spotkać się ze znajomymi z branży i mieć sposobność poznania ludzi spoza mojego środowiska programistycznego. Cieszę się, że GeeCON sięga po nowe obszary, bo dzięki temu dochodzi do spotkania osób wcześniej niemających wiele okazji do choćby minimalnej interakcji i wymiany doświadczeń. Kolejny raz GeeCON staje się platformą inspiracji i wymiany doświadczeń dla polskiej sceny informatycznej. Gratulacje wytrwałości!

W trakcie konferencji spotkałem się z osobami, które zawsze mają wiele wartościowego do powiedzenie i nawet, jeśli wciąż jeszcze nie zrozumieli, że język programowania Scala jest…ekhm…najlepszy, to warto ich wysłuchać i porozmawiać. Dobrze było spotkać Łukasza i Adama (z poznańskiej części organizacyjnej GeeCON), Adriana i Adę (z części krakowskiej), Diablo (również znaną jako Dominika i też z Krk), Szymona i Piotrka (z załogi toruńskiej), Jacka (Pzn), Kubę K. (Waw), Jakuba M. (Pzn), Kubę M. (Gdn). Nie mógłbym pominąć przyjemności uściśnięcia dłoni Steve'owi Freemanowi oraz Nata Pryce.

Ślę również obiecane pozdrowienia dla zespołu IT Kontrakt! Życzę powodzenia GFT (dawniej Rule Financial) w ekspansji na południe (z wyrazami ubolewania, że do uruchomienia oddziału w Gdańsku jednak nie doszło).

Ufam, że do zawiązania poznańskiej grupy miłośników języka Scala pod przewodnictwem Radka (Gallera) z pomocą Konrada z Allegro dojdzie i publicznie deklaruję swoją pomoc, aby taki pomysł doszedł do skutku. Radek, jak się powiedziało A, to trzeba powiedzieć i B! Powołanie grupy to pierwszy etap i później przy ustalonych regularnych spotkaniach już będzie z górki. Pomożemy!

Dziękuję Kubie Kubryńskiemu za krótkie acz treściwe wprowadzenie do Spring Boot -- chwila z mądrym i czułem jak staję się mądrzejszy. Nie przyjdzie mi użyć tego narzędzia w najbliższej przyszłości, ale wiedzieć, do czego służy, nigdy nie zawadzi. Sugeruję rozważyć serię spotkań, które przybliżyłyby Spring Boota szerszej publiczności. Rozważ to koniecznie! Może seria nagrań na YouTube lub vimeo?

Podczas konferencji dowiedziałem się o istnieniu firmy Comarch w Poznaniu. Otrzymałem wstępne zaproszenie do współpracy w promocji Scali, więc jeszcze o nich usłyszymy na łamach tego bloga. I nie mógłbym zapomnieć o Anecie z Comarch, która niedługo również wejdzie w temat programowania w języku Scala, bo…licencja IntelliJ IDEA czeka. I ja na pull requesty na GitHubie również.

Wygląda na to, że firma CommerceOne z Łukaszem i Jackiem to całkiem ciekawa firma w Poznaniu. Historia powołania firmy na pewno. Technologicznie jeszcze mają dużo do nadrobienia, ale wierzę, że z takim składem osobowym, to wyłącznie kwestia czasu. Trochę szkoda Espeo,  ale skoro stawiają na PHP, to…ich dni są policzone. Ble.

Dzięki PSI za podarunki i test ze znajomości Javy! Nie było lekko, co należy wyłącznie zrzucić na barki dawno nie używanej przeze mnie Javy. Gadżety czekają na rozdanie podczas kolejnego spotkania scalowego w Warszawie. Więcej na stronie @WarszawScaLa.

Szymon przypomniał mi o pomyśle nagrywania wstępniaków scalowych z kimś. Trzeba to wdrożyć w lutym! Dzięki Szymon za przypominajkę. Hmmm, momento, czyżby liczył, że to właśnie jego zaproszę?! Ciekawa oferta! Oczekuj kontaktu w sprawie.

Podsumowując, konferencję GeeCON TDD wstawiam do kalendarza jako imprezę wartą udziału. Polecam ją jako dobry wstępniak do różnorodnych technologii i technik informatycznych. Swoje wystąpienie uważam za przyzwoite, a pomysł 30 minut na występ określam za strzał w dziesiątkę - wystarczający na przekazanie dostatecznej informacji, aby zaintrygować tematem. Bardzo, bardzo dobry pomysł warty podtrzymania (i skopiowania przy innych imprezach)! 30 minut to dokładnie tyle, ile się należy o temacie i bez dodatków w stylu slajd o mnie czy dowcipów (co podobno Kubie ze slajdem o mnie się nie bardzo udało).

Dziękuję organizatorom i uczestnikom za bardzo miłą atmosferę i zapraszam na kolejną edycję. Sztandarowy produkt — konferencja GeeCON 2015 — już 13-15 maja 2015 w Krakowie. Do zobaczenia!

Łącząc przyjemności - o TDD i spacerze "nagraniowym" z Maksymem

Warto czasami przystanąć, zastanowić się i po prostu pomyśleć bez jakichkolwiek zewnętrznych "przeszkadzaczy". Doświadczyłem błogosławieństwa takich chwil niedawno dwukrotnie i nie mogłem uwierzyć, jak niewiele trzeba, aby mieć ich więcej.

Podczas konferencji JDD w Krakowie (czytaj Wrażenia pokonferencyjne - zacznijmy od JDD w Krakowie) miałem przyjemność uczestniczyć w sesji "TDD Coding Dojo" z Krzyśkiem Jelskim i Marcinem Zajączkowskim. Kiedy wracałem do domu pociągiem, a może jeszcze wcześniej, w taksówce, zacząłem zastanawiać się nad słowami Jakuba Nabrdalika, który kiedyś stanowczym tonem stwierdził, że nie da się robić TDD z już gotową aplikacją. Miałem wtedy wrażenie, że Kuba jest tak etycznie upośledzony przez TDD, że jedyną, słuszną drogą dla TDD jest zacząć od testów. Ja jednak bardzo nalegałem na możliwość dopisywania testów do gotowej aplikacji (projekt Apache OpenEJB), aby stworzyć siatkę bezpieczeństwa dla późniejszych prac przy zmianie kodu. Nie pomagał nawet mój wrodzony wdzięk. Po prostu, Kuba kończył taki pomysł stanowczym: "To nie będzie TDD" i tyle mi było z nim rozmawiać. Oj, jaki ja byłem na niego zły za takie potraktowanie. Nie żebym czuł jakąś zadrę do niego za to, ale po prostu nie mogłem zrozumieć, dlaczego to nie przejdzie.

I właśnie podczas powrotu do Warszawy, po sesji z Krzyśkiem i Marcinem, olśniło mnie! Wydaje mi się, że zrozumiałem ideę TDD. Wreszcie połączyłem teorię z praktyką i jakkolwiek nie było tego drugiego wiele, to wystarczyło, abym usnął tezę, która wydaje się zgodna z myśleniem Kuby (!) Nie zapomnę tej chwili, kiedy prawie wykrzyknąłem "Eureka!"

TDD stosujemy jako "zapalnik" zmian w aplikacji. Pojawia się test, nie przechodzi (czerwono), piszemy minimalistyczną implementację, taką, aby jedynie pozwoliła przejść testowi (pojawia się zielone), refaktoring i tak w kółko. Kiedy zastanowić się nad kolejnością zmian w aplikacji - najpierw test, później minimalnistyczna implementacja i tak, aż do znudzenia, to łatwo zrozumieć, że aplikacja ma tyle, aby jedynie/aż przeszły testy. Nic więcej. Jeśli jest więcej, to prawdopodobnie możemy liczyć się z miejscami niepokrytymi testami. Całkiem zrozumiałe, jeśli para programistów jest więcej niż początkująca w temacie programowania i TDD w ogólności.

Weźmy teraz działającą aplikację. Skoro działa, to każdy kawałek kodu, który mógłby wyglądać na potencjalny błąd...NIE jest błędem! Na pewno nie jest nim jeszcze. Gdyby już był, to pojawiłaby się poprawka i...po błędzie. I teraz pora na moje olśnienie - wręcz niemożliwym jest pisanie testów, które objęłyby wszystkie możliwe przypadki do przetestowania dla działającej aplikacji. Słyszałem o narzędziach automatyzujących, które prześwietlając kod wykrywają "zakręty" na if'ach i temu podobnych konstrukcji "rozgałęziających", ale, właśnie, to są automaty. Gdyby pisać je ręcznie, to nigdy nie wiadomo, czy jest ich wystarczająco wiele, aby powiedzieć, że jest ich wystarczająco wiele. Właśnie to odwrócenie zależności między testami a aplikacją jest problemem. Nie można mówić o odwróceniu zależności w przypadku TDD, gdzie zależnością aplikacji są testy. A może na odwrót? Tak czy inaczej, jeśli zakładamy, że dla testu sprawdzającego, czy zwrócono liczbę 5 piszemy kod, który po prostu zwraca 5, to nie ma szansy na pomyłkę. Kod może być dalej pod kątem zaawansowania funkcjonalnego, ale należałoby to odznaczyć jako...nadgorliwość. Oczekujemy 5, to nie ma potrzeby wywoływać usługi RESTowej, która zwraca 5, bo wystarczy zwrócić 5. Proste i oczywiste.

Czy moje zrozumienie TDD jest właściwe? Czy takiego myślenia oczekuje się od praktyków TDD? Chętnie poznam Twoją opinię. W komentarzach jest duuuużo miejsca na dywagacje.

Kolejnym momentem, w którym doświadczyłem momentu olśnienia był dzisiejszy spacer z Maksymem. Kolejny samotny spacer przez 1,5-2h to nie przelewki. Łazisz po utartych ścieżkach Lasu Kabackiego i tak idziesz, i idziesz, i idziesz. Można kota dostać.

Z drugiej strony, kilka dni temu odznaczyłem sobie kilka nagrań z konferencji do odsłuchania i wcale mi się nie uśmiechało odsłuchiwanie ich podczas siedzenia w domu. Każdorazowo, kiedy próbowałem usiąść nad nimi w domu, zawsze pojawiało się zniecierpliwienie i w ogóle ogólna niechęć do ślęczenia przed kompem i gapienia się w monitor z założonymi rękoma. Nuda. Nosiło mnie moje wewnętrzne ADHD. 30 minut jeszcze dam radę słuchać, ale więcej?! Nie ma mowy! No i jeszcze mógłbym nie usłyszeć Maksyma, kiedy się obudzi i daje znać o tym wszem i wobec!

I tak dzisiaj przypomniałem sobie o tych nagraniach i idąc Lasem Kabackim włączyłem Language Panel o językach programowania. Byłem ciekaw, co też tam Ci myśliciele mówią o językach. Skoro i tak miałem ponad godzinę czasu na spacer, to przecież mogłem go spędzić łącząć przyjemne z pożytecznym.

I tak ze słuchawkami na uszach (głos) i smartfonem w nogach Maksyma (wizja) zeszło mi przyjemnie 40 minut. Las gwarantował spokój, brak zewnętrznych przeszkadzaczy i wiatru, który szalejąc na osiedlu tutaj zanikł kompletnie. Przyjemna sprawa.

Początkowo planowałem godzinny spacer, ale kiedy minęło mi 40 minut, stwierdziłem, że pozwolę sobie na dłuższy spacer i...ponad godzinne nagranie Clojure and the Web. Nie polecam tego nagrania, ale dla napaleńców może być ciekawym podsumowaniem zalet Clojure (przez pierwsze 20 minut) oraz przegląd szkieletów webowych w Clojure z praktycznym przeglądem Ring w drugiej części.

Po 2,5 godzinach wróciłem do domu wyjątkowo zadowolony (!) Maksym przez całą drogę spał smacznie, ja przejrzałem 2 nagrania, co dało nam obu sporą dawkę świeżego (?) powietrza, a reszta rodzinki odetchnęła na jakiś czas od Maksyma. Już nie mogę doczekać się kolejnego spaceru! Co proponujecie do obejrzenia? Może coś w tematyce TDD? Zastanawiam się, czy pomysł odsłuchiwania na mrozie wypali. Ale w końcu i w Norwegii używają Galaxy S2, a tam ciągle zimno.

Recenzja "Growing Object-Oriented Software, Guided by Tests"

Jeszcze niedawno byłem w Turcji, gdzie wylądowałem w pokoju 722, aby w tym tygodniu poprowadzić szkolenie WB722 Administration of IBM WebSphere Process Server V7 w Bratysławie, Słowacja. Chodzą przypadki po ludziach, a mnie nawiedziła liczba 722 (!)

Siedzę sobie w hotelu i korzystam z czasu na czytanie książek. Na tapecie było kilka, ale zdecydowałem się dokończyć jedną, szczególną - Growing Object-Oriented Software, Guided by Tests. Wciąż nie mogę uwierzyć, jak można mieć tyle wiedzy technicznej, a jednocześnie umiejętnie przedstawić temat w postaci książki?! Niekrótka "wycieczka" w stronę Test-Driven Development (TDD) trwała dobrych kilka tygodni i wczoraj udało się ją zakończyć recenzją.

To była lektura, która na długo pozostanie mi w pamięci. Była to z pewnością jedna z tych nielicznych, jeśli nie jedyna, która nie traktowała o produkcie lub specyfikacji, ale o sposobie postępowania podczas rozwoju oprogramowania (możnaby powiedzieć, że faktycznie przedstawiała jMock, ale zorientowałem się dopiero przy końcowych rozdziałach, więc nie to mną kierowało). Niby wiele rzeczy oczywistych, a mimo wszystko niezwykle zwięźle i treściwie przedstawione. Najbardziej podobała mi się część Part III: "Working Example", w której mogłem poczuć na własnej skórze, co autorzy mieli na myśli w poprzedzających ją 2 częściach - Part I: "Introduction" oraz Part II: "The Process of Test-Driven Development". Pamiętam jak dziś, kiedy powiedziałem sobie "STOP, więcej nie mogę!", kiedy czytanie zaczęło mi zabierać coraz więcej czasu, bo...po prostu analizowanie treści angażowało mnie w trakcie, jak i po skończonym czytaniu. Nie minął miesiąc, kiedy zdecydowałem się powrócić do lektury. Jednym słowem warto było i tylko szukać miejsca, aby rozpocząć wdrażanie tych mądrości w życiu. Zdecydowany numer 1 na mojej półce czytelniczej.

W międzyczasie, całkiem przypadkiem trafiłem na prezentację Sustainable Test-Driven Development autora wspomnianej książki Steve'a Freemana, który w ciągu 50 minut przedstawił kwintesencję zawartości książki z części Part IV: Sustainable Test-Driven Development. Odsłuchanie prezentacji zajęło mi dokładnie tyle czasu, ile potrzebowałem na...odprasowanie rzeczy na mój słowacki wyjazd (!) :) Doskonały przykład łączenia przyjemnego z pożytecznym. Warto wysłuchać, aby wzmocnić przekaz książki, albo wręcz ocenić jej zawartość przez pryzmat prezentacji.

Zainteresowanych moją angielskojęzyczną recenzją kieruję do Book review: Growing Object-Oriented Software, Guided by Tests, a samą lekturą książki o kontakt na priv. Książka jest w zbiorach Biblioteki Warszawskiego JUGa i dostępna na żądanie dla każdego, szczególnie tym, którym leży na sercu podniesienie jakości tworzonego oprogramowania i przyjaźń współtowarzyszy na projektach :-)

Natychmiast pochwaliłem się wydawnictwu o moim wyczynie - opublikowaniu recenzji na Amazonie i nieśmiało poprosiłem o kolejną:

With the review published would I qualify for one more? I wish I could review "Clean Code: A Handbook of Agile Software Craftsmanship" [2] if possible.

[2] http://www.informit.com/store/product.aspx?isbn=0132350882

Odpowiedź nadeszła następnego dnia, a w niej:

Jacek,

Thank you for this review and we will be pleased to ship you "Clean Code".

Heather Fox

Od razu świat wydał mi się przyjaźniejszy :-) Czekam cierpliwie na przesyłkę, a nim nadejdzie urozmaicam sobie czas innymi aktywnościami. Pozwoliłem sobie między innymi na chwilkę z WebSphere Application Server Administration Using Jython, ale albo zmęczonym i do mnie nie dociera, albo nie przystaje do moich oczekiwań i nie pozostanie mi nic innego, jak ocenić ją jako bezwartościową. Odkładam na bok, bo szkoda urazić autorów zawczasu. Wypocznę, ona odleży swoje i może się dogadamy.

Tym samym wracam do lektury specyfikacji JSR-299: Context and Dependency Injection for the Java EE platform, bo po zakończonym 1 rozdziale czekała na mnie cierpliwie i pora zrewanżować się chociażby niewielkim zainteresowaniem :-)

p.s. Jak widzę po liczbie wpisów z ostatniego tygodnia, to chyba nici z moich publicznych deklaracji Wygaszam bloga na rzecz innych aktywności - głównie skrinkasty i wtyczka NetBeans do WAS8. Faktycznie zająłem się intensywniej skrinkastami (mam scenariusz i kilka podejść próbnych) oraz wtyczką NetBeans do WAS8 (już można zarejestrować WAS8 i pojawia się pozycja w Servers), więc poza wygaszaniem, wszystko zgodnie z planem.

Grails a TDD z perspektywy "Growing Object-Oriented Software, Guided by Tests"

Książka jest od dzisiaj obowiązkowa dla kogokolwiek, komu przyjdzie pracować ze mną, aby...zrozumiał moje postępowanie :)

Rozpocząłem rozdziały praktyczne w części Part II. The Process of Test-Driven Development i nie mam wątpliwości, że teoria, a teraz praktyka (wciąż jednak tylko w postaci lektury książki), pozostawią trwały ślad w moim postrzeganiu programowania. Uległem książce całkowicie i czuję się lekko rozdarty.

Z jednej strony książka nawołuje do rozpoczynania projektów od przekrojowych testów integracyjnych, gdzie testuje się wybrane funkcjonalności docelowej aplikacji...bez jej istnienia (chociażby jednej maluczkiej klaski), a z drugiej mam świadomość (albo i nie, ze względu na brak praktycznego doświadczenia), że potrzebna wiedza na początku projektu i do zrobienia tego pierwszego kroku jest niebagatelna, a nerwy trzeba trzymać mocno na postronku. Moje rozpalone są do czerwoności. Chciałoby się trochę poszaleć programistycznie, a tu każą uzbroić się w cierpliwość i zbudować szkielet testujący wybraną funkcjonalność. I nie ma to być trywiał w stylu odczyt z bazki, ale w przypadku aplikacji webowej, najlepiej uruchomić przeglądarkę, wskazać właściwą stronę i sprawdzić wynik! Dla mnie to novum, bo pisanie testów sprowadzałem zwyczajnie do testów jednostkowych, jeśli w ogóle.

W przypadku Grails sprawa się znacznie upraszcza, bo wykonanie dowolnego polecenia budującego typu grails create-controller czy grails create-domain-class tworzy nie tylko wskazany artefakt, ale i...test integracyjny (!) Człowiek, czy chce, czy nie, ugrzązł w TDD na dobre. To, czy wyjdzie to na dobre i czy w ogóle skorzysta się z tego dobrodziejstwa jest tematem na inne przemyślenia, ale fakt faktem Grails zdaje się być pomocnym. Czy aby rzeczywiście można nazywać to "pomocnym"?

I tu pojawiła się moja wątpliwość. Nawet, jeśli Grails faktycznie tworzy testy integracyjne dla wybranego artefaktu czy stworzymy go explicite z grails create-integration-test, to zastanawia mnie, czy to faktycznie odpowiada początkowemu testowaniu integracyjnemu z TDD jak opisano w tej książce. Zdanie z dokumentacji grails create-integration-test:

An integration test differs from a unit test in that the Grails environment is loaded for each test execution.

uspokaja mnie nieznacznie, bo w końcu cała infrastruktura Grails jest uruchamiana w całości przy każdym teście, ale zastanawiam się, czy nie powinienem raczej zbudować war (grails war), uruchomić Tomcata z podłączoną zewnętrzną bazą danych, wdrożyć i uruchomić aplikację i po uruchomieniu przeglądarki uruchomić testy integracyjne (pewnie z pomocą Selenium)?! Znacznie to więcej roboty, ale faktycznie odpowiada bardziej docelowej architekturze, a tak zrozumiałem potrzebę rozpoczęcia prac z testami integracyjnymi, które najbardziej zbliżą nas do docelowego środowiska produkcyjnego. Czy przypadkiem nie poniosło mnie za bardzo? Pomocy!

"Nie ma geniuszu bez ziarna szaleństwa" - "wątpliwa" lektura o TDD z "Growing Object-Oriented Software, Guided by Tests"

O Test-Driven Development (TDD) każdy gdzieś tam słyszał i niejeden obiecywał wdrożenie jego zasad. Jednym się udaje (albo sądzą, że tak jest), a inni polegli i zarzucili temat. Smutna prawda, ale prawda. Pewnie w dużej mierze dlatego, że pomimo wiadomych zysków - przede wszystkim skoncentrowanie na celu, jakim jest stworzenie działającego oprogramowania, zamiast rozdmuchiwania modelu, później kontrolerów, później widoku i jeszcze tysiąca innych warstw, aby ostatecznie przekonać się, że połowy nie potrzebowano, albo że i tak nie wiadomo, po co i na co, a termin i klient dawno poszli w zapomnienie - wdrożenie takiego podejścia wymaga niezwykłego zdeterminowania zespołu do zrealizowania postawionego celu. Innymi słowy - rygoru i dyscypliny! A kto by tam lubił rygor i dyscyplinę?! Niewielu osobom kojarzy się to z czymś przyjemnym. Mi na pewno nie.

Po recenzji Tomka Kaczanowskiego "Growing Object-Oriented Software Guided by Tests - Book Review" i namowie Bartka "Koziołek" Kuczyńskiego (Fwd: A free copy of "Growing Object-Oriented Software, Guided by Tests" for review doable?), aby ją zamówić do Biblioteki Warszawskiego JUGa dotarła i do mnie. W zeszłym tygodniu rozpocząłem jej lekturę i...jestem pod ogromnym jej wrażeniem. Niesamowicie nabałaganiła w mojej głowie. Stąd to użycie słowa "watpliwa" w tytule wpisu, bo narodziło mi się wątpliwości cała masa (i oby nie zakończyło się psychiatrą :)).

Książkę "Growing Object-Oriented Software, Guided by Tests" panów Steve Freeman i Nat Pryce (Oct 12, 2009 by Addison-Wesley Professional) czyta się lekko i przyjemnie. Jestem przy rozdziale 11. "Passing the First Test" (z 27-miu i 2 dodatków), więc praktycznie (dosłownie i w przenośni) niewiele mogę o niej napisać, ale mimo jej początkowego namolnego przekonywania o wyższości TDD nad tradycyjnym podejściem do tworzenia oprogramowania (najpierw model, później interakcje w jego ramach z testami jednostkowymi w międzyczasie), widać jedną wyraźną różnicę w moim postrzeganiu TDD, a tym, co autorzy rozumieją pod tym akronimem.

Do tej pory sądziłem, że TDD to przede wszystkim testy, co jest do tego momentu prawdziwe. W moim jednak rozumowaniu były to przede wszystkim testy jednostkowe przy tworzeniu konkretnych klas (dowolnej warstwy). W tej książce dowiedziałem się prawdy i to nie takiej, jakiej oczekiwałem początkowo. Miałem świadomość różnic w moim postrzeganiu TDD a jego zasadami, głównie z braku praktycznego doświadczenia i niezbyt dalekoidącym zainteresowaniem tematyką, ale to, w jaki sposób TDD przedstawia ta książka przeszło moje najśmielsze oczekiwania. Sprawa rozbija się o te "nieszczęsne" testy. Książka podzielona jest na 5 części, z których pierwszą mam już za sobą Part I. "Introduction", w której dowiedziałem się o teorii TDD i testach...funkcjonalnych, ale nie takich, które weryfikują przydatność gotowego produktu przez klienta (prawdopodobnie wykonanych wspólnie z nim manualnie), ale takich, które zweryfikują automatycznie, że dana funkcjonalność jest gotowa do testowania końcowego z klientem (!) To było dla mnie zabójcze doświadczenie, kiedy dodać do tego, że owe testy tworzy się zanim cokolwiek w naszej aplikacji powstanie, nawet infrastruktura. Czyż to nie (sarkazm włączony) "odświeżające" podejście (sarkazm wyłączony)?!

Zatem, jeśliby potraktować podejście książkowe, to zaczynamy od przekrojowego testu wybranej, pierwszej, zwykle łatwej do osiągnięcia, funkcjonalności końcowej aplikacji. Nie piszę tutaj o testach klasy XYZ, czy testach użyteczności technologi ABC, ale o pokrojeniu całej ostatecznej aplikacji (znanej na bazie dotychczasowych wymagań klienta) na kawałki funkcjonalne - rozpoczynające się od interfejsu użytkownika, a kończące się na systemach wewnętrznych - i bez rozstawionej infrastruktury stworzenie dla wybranego kawałka testu. Z oczywistych względów nie będzie to działający test - nic nie mamy - ale właśnie o to chodzi. Tylko, który zespół to wytrzymuje?! Chyba tylko te najbardziej zdeterminowane, zdyscyplinowane i...tu należałoby dopisać inne zalety zespołów, o których istnieniu nie miałem pojęcia. Jeśli takie istnieją, koniecznie muszę się dowiedzieć o ich stanie duchowym, kiedy nic nie ma, a trzeba stworzyć dla tego czegoś nieistniejącego kod testujący, w którym czerwonego więcej niż czarnego (czerwone to podkreślenie błędu w IDE, a czarne to wpisane litery składające się na test). W/g mnie praca w takim zespole może być tylko przywilejem, a dostosowanie się do reguł TDD...szaleństwem. W tym ujęciu jednak "szaleństwo" jest dla mnie czymś niezwykłym i zagadkowym. "Choć to szaleństwo, jest w nim przecie metoda" powiedział William Shakespeare w Hamlecie, ale podobają mi się też takie powiedzenia (zaczerpnięte z Wikicytaty) - "Kto ukrywa własne szaleństwo, umiera niemy" czy "W szalonym świecie tylko szaleńcy są rozsądni" i "Nie ma geniuszu bez ziarna szaleństwa". Naczytanie się takich powiedzonek nie może pozostać obojętne na nasze postrzeganie świata i podobnie jest z tą książką.

Zgodnie z nią, pierwsza faza TDD to stworzenie testu przekrojowego zwana The Walking Skeleton. Ów "chodzący szkielet" to szkielet przyszłego rozwiązania funkcjonalnego. Jego zadaniem jest sprawdzenie naszej świadomości architektonicznej tworzonej aplikacji i zaproponowanie architektury docelowej. Najlepiej jest, aby test był niewielki, ale dotykał wszystkich warstw, począwszy od interfejsu końcowego użytkownika a skończywszy na systemach zewnętrznych. W książce tworzony jest system aukcyjny jako samodzielna aplikacja desktopowa w JFC/Swingu i komunikująca się przez XMPP (w tej roli Smack) z płatnym systemem aukcyjnym. Do testowania GUI w Swingu wykorzystuje się WindowLicker, o którym nigdy wcześniej nie słyszałem (co, choćby z tego tylko powodu, już stanowi wartość z czytania tej książki). Dopiero w rozdziale 11. "Passing the First Test" przekonam się, jak autorzy zestawiają całe środowisko, więc nie napiszę, co o takim podejściu myślę teraz, poza tym, że jestem równie zdruzgotany, jak niewiele wiedziałem o TDD, jak zaintrygowany nowatorskim podejściem do tworzenia oprogramowania. Oby mi się nie udzieliło, bo nieznającym tematu ciężko będzie zrozumieć...szaleńca :)

Na bazie doświadczeń z tej książki chciałbym zrealizować pewien swój pomysł na aplikację desktopową z GUI w JFC/Swingu. Jednym z problemów, z jakim się obecnie borykam, to wybór między Eclipse RCP a NetBeans RCP. O tych słyszałem, że warto je rozważyć, ale może są inne? Chciałbym, aby tworzenie GUI było równie proste, co ostatnio stworzona przeze mnie aplikacja w Objective-C/Cocoa w Xcode na bazie lektury Introduction to Cocoa Application Tutorial. To było tak niezwykle proste, że uwierzyłem w swoje ukryte pokłady wiary na powrót do C w wersji obiektowej i na MacOS :) Nie chciałym jednak wchodzić w ten temat, kiedy tworzę aplikację GUI przede wszystkim na MS Windows i Linuksa, a Mac OS przy okazji, więc pewnie wybór padnie na Eclipse RCP vs NetBeans RCP. Jako, że nie chciałbym wracać do silnie typizowanego programowania w Javie i Swingu, więc przyjdzie mi skorzystać z Griffon, który jest (jak rozumiem) połączeniem NetBeans RCP i Groovy. Jak się coś nawinie z Clojure może zrobię przeskok, ale na chwilę obecną tnę moje żądze do realizowalnego minimum.

A jak Wam idzie TDD z tworzeniem aplikacji desktopowych w JFC/Swing, NetBeans RCP czy Eclipse RCP? Co polecacie na warsztat? Gdyby jeszcze było na tyle lekkie, aby dało się to puścić przez Java Web Start byłoby cudnie (aczkolwiek jest to wymaganie niewielkiego znaczenia).