Studio Pragmatists

NYAC i Javarsovia

2010-06-24T20:46:00.001+02:00

W zeszły weekend odbyła się NYAC - nowa konferencja organizowana przez Grześka Dudę. Miałem przyjemność być zaproszonym do prowadzenia tam paru prelekcji, więc chciałem się z Wami podzielić moimi odczuciami.

Zacznijmy od kwestii merytorycznych. Agenda konferencji była zdecydowanie ciekawa. Mniej technologiczna niż większość konferencji, za to skupiona na jakości oprogramowania, technikach programistycznych, projektowaniu oprogramowania itp. Idea Grześka była taka, żeby prezentacje były mniej wykładowe, a bardziej w charakterze dyskusji. Myślę, że to fajna formuła, zachęcająca ludzi do dzielenia się doświadczeniami i wiedzą. I wg mnie ta formuła się sprawdziła. Ludzie stali na korytarzach w kółeczkach i rozmawiali. Również w czasie wykładów zawiązywały się dyskusje i wymiana doświadczeń.

Organizacyjnie - myślę, że mogłoby być trochę lepiej (wizyta w tym hotelu to jak powrót do czasów 'Misia'), ale to pewnie związane ze sposobem finansowania konferencji.

Update: nie napisałem, że część konferencyjna była naprawdę ok. No może poza projektorem w głównej sali ;-)

Ja na NYAC'u opowiadałem o:
- architekturze w zwinnych projektach
- wdrażaniu zwinnych praktyk w zespołach programistycznych
- razem z Bartkiem Bańkowskim kodowaliśmy (TDD) na żywo
- wraz z Bartkiem Bańkowskim i Szczepanem Faberem pokazywaliśmy testy akceptacyjne w różnych podejściach i technologiach - ja oczywiście pokazywałem Tumbler'a

A już pojutrze Javarsovia, na której opowiem o tym jak pisać testy, żeby były czytelne i wiecznie użyteczne. Zapraszam!

Szkolenie TDD - retrospekcja

2010-05-24T08:36:00.004+02:00

Już trochę czasu minęło od pierwszego otwartego szkolenia Test-Driven Development, które miałem przyjemność prowadzić. Było to dla mnie na tyle ważne doświadczenie, że nadal odczuwam potrzebę podsumowania go. Zatem do dzieła...

Uczenie programistów techniki TDD dało mi mnóstwo satysfakcji. Świetne było obserwowanie postępów uczestników. Widziałem też, że bardzo podobało się im podejście do programowania, w którym wiele "robi za nas" eclipse - chodzi o generowanie kodu i refaktoryzacje. TDD znakomicie promuje wykorzystanie możliwości IDE - w końcu chcemy ułatwić sobie życie i jak najwięcej robić automatycznie. No i okazuje się, że zaczynanie od testów sprawia, że powstaje więcej kodu, ale wcale nie tak dużo więcej go piszemy.

Podczas szkolenia starałem się nie zanudzać wykładami, prowadziłem natomiast dużo warsztatów. Podobało się to uczestnikom i myślę, że to właśnie praktyczne doświadczenie TDD jest najcenniejsze w tego typu szkoleniach.

Okazało się, że znakomicie zadziałało programowanie w parach. Wszyscy chętnie pracowali w ten sposób (co prawda nie jednocześnie, gdyż liczba osób była nieparzysta :) Praktyka programowania w parach doskonale uzupełnia się z TDD - cykl Red-Green-Refactor daje naturalne momenty zmiany drivera. Dodatkowo świetny jest aspekt uczenia się od siebie nawzajem oraz doświadczenia różnych stylów programowania. Było na przykład tak, że jedna para wypracowywała pewien sposób pisania testów, który podczas następnego ćwiczenia "migrował" dalej (przed każdym warsztatem następowała zmiana w parach).

Co do prowadzenia wykładów - doświadczyłem ogromnego znaczenia pilota do prezentacji. Pierwszego dnia zapomniałem go wziąć. Aby móc zmieniać slajdy, musiałem mówić stojąc blisko laptopa. Natomiast użycie tego urządzenia podczas następnych dni pozwoliło mi opowiadać dużo swobodniej - chodzić po sali, częściej utrzymywać kontakt wzrokowy ze słuchaczami. Zupełnie inna jakość.

Z rzeczy do poprawienia to na pewno warto uzupełnić prezentacje większą ilością przykładów - kodu i może trochę UMLa przy tematach z projektowania. Jeden obraz wart tysiąca słów, a kilka slajdów z kodem z pewnością równoważy wiele minut opowiadania "na sucho". Myślę tu głównie o refaktoryzacjach, zwłaszcza tych dotyczących kodu odziedziczonego. Ewentualnie zamiast kodu w prezentacjach niezłe mogłoby być też kodowanie na żywo.

No i jakoś nie wyszło mi Aha Experience Exercise. Owszem, kilka "Aha!" pojawiło się na początku, gdy wprowadzałem to ćwiczenie, ale w trakcie już nie dochodziły kolejne.

Z niecierpliwością czekam na kolejną okazję, kiedy będę mógł wykorzystać doświadczenie z tego szkolenia i poprawić swój warsztat trenera i programisty. Tak, tak, programisty też - podczas wspólnego kodowania ja też uczę się od uczestników. Dziękuję!

Javarsovia 2010

2010-05-19T19:48:00.000+02:00

Wczoraj kapituła Javarsovii wysłała mi email, że moja prezentacja została zaakceptowana. Tak więc z przyjemnością ujawniam o czym będę mówił w tym roku:

Temat: "Clean Tests" by Uncle Paul, czyli jak pisać testy, żeby dobrze Ci służyły.
Abstrakt: Niewielu programistów ma dobry zestaw testów dla swoich aplikacji. Jeszcze mniej ma takie, które są zarówno dobrą “siatką bezpieczeństwa” przy realizacji jakichkolwiek zmian, ale również mogą służyć za zawsze aktualną dokumentację systemu. W czasie prezentacji pokażę jak pisać i refaktoryzować testy by się je łatwo czytało, nietrudno utrzymywało, oraz by dobrze dokumentowały aktualny stan systemu.

Tumbler 0.2.1

2010-05-17T23:07:00.001+02:00

Dzięki aktywności Bartka Zdanowskiego (a dokładniej jego niedoczytaniu dokumentacji ;-)) wypuściłem wersję 0.2.1, która jasno mówi jak coś jest nie tak. Czyli jak jest JUnit <4.6 albo ktoś używa @Test zamiast @Scenario. No more NPEs ;-)

Do tego Tumbler 0.2.1 pojawi się w repo maven'a pewnie już jutro. Szczegóły będą na stronie Tumbler'a.

Aktualizacja:
Tumbler jest już w repo mavenowym.
groupId: pl.pragmatists.tumbler
artifactId: tumbler

Tumbler 0.2.0

2010-05-14T23:01:00.008+02:00

Przez ostatnie dwa tygodnie znowu znalazłem trochę czasu i dorobiłem do Tumblera rzeczy, których brakowało. Dzięki temu wydałem właśnie wersję 0.2.0. W sumie powinienem chyba dobić do 1.0.0, bo w tej chwili ma on wszystkie podstawowe cechy takiego narzędzia, ale jakoś jeszcze nie jestem przekonany do takiego skoku w numerku.
Co się zmieniło?

Zmieniłem moje wynalazki: Subject i Example na standardowe w BDD Story i Scenario. One może troszkę gorzej oddają o co chodzi, ale za to są spójne z zapisem Dana North'a używanym m.in. w JBehave, NBehave i jeszcze pewnie gdzieś indziej. A nuż ktoś będzie się chciał zmigrować, to będzie miał łatwiej. A i czytelnicy Dan'owych artykułów od razu zmapują sobie jego idee na Tumblerową rzeczywistość.
Dodałem raporty w HTML. Jeśli to ma być narzędzie używane jakoś przez biznes, to musi być dla nich czytelne. Można używać własnych szablonów (freemarker) albo domyślnego. Zgodnie z sugestią Szczepana Fabera jest też "spis treści" dla stories, wraz ze statystykami wykonania dla całego projektu.
Za namową Lasse Koskeli usunąłem @CamelCase. Jeśli ktoś nie chce pełnych zdań w eclipsie, to niech sobie ustawi zmienną -DcamelCase=true. W ten sposób nie wpływa na resztę zespołu.

W sumie więc nie ma tak dużo nowości, ale z drugiej strony myślę, że użyteczność narzędzia wzrosła znacznie.

Bardzo chciałbym się dowiedzieć co myślicie o tym narzędziu. Co można by dodać, co powinno być inaczej.

Tumbler działa tylko z nowymi wersjami JUnit'a. Wersja domyślnie będąca w eclipsie, jest dość stara (i buggy) - 4.5. Do poprawnego działania Tumbler wymaga wersji 4.8. Użycie starszej wersji JUnit'a skutkuje następującym wyjątkiem:

java.lang.NoSuchMethodError: org.junit.runner.Description.getMethodName()Ljava/lang/String;
at tumbler.internal.ScenarioListener.isItSingleScenario(ScenarioListener.java:97)
at tumbler.internal.ScenarioListener.testStarted(ScenarioListener.java:92)
at org.junit.runner.notification.RunNotifier$3.notifyListener(RunNotifier.java:83)

Behaviour-Driven Development

2010-05-13T23:57:00.000+02:00

Tak sobie ostatnio pomyślałem, że wyjechałem z tym Tumblerem bez przybliżenia najpierw o co w nim chodzi. To znaczy wyjaśniłem (mam nadzieję) o co w NIM chodzi, ale nie pisałem nigdy o samej idei na której on bazuje, czyli BDD. Samo hasło pewnie większość z Was słyszała, ale ciekawy jestem jaki procent wie o co w tym chodzi (nic, i tak się nie dowiem).

No więc BDD wywodzi się od Dana North'a (kiedyś z Thoughtworks, teraz nie wiem), który doszedł do wniosku, że jest jakaś dziura między tym co zwykle programiści myślą o projekcie, który robią, a tym czego oczekuje biznes. Główny problem jest taki, że każda z tych grup mówi innym językiem - biznes zasuwa wyłącznie o pieniądzach, a programiści chcą mieć wszystko wyłożone w javie. No więc Dan wpadł na pomysł jak to połączyć.
Po pierwsze trzeba się uporać z językiem - nie ma sensu, żeby każdy nazywał rzeczy po swojemu, więc Dan doszedł do wniosku, że skoro nas klient nas Paaaannnnnn to wszędzie należy używać tej nomenklatury (tak, to to samo co Ubiquitous Language w DDD).
Po drugie biznes(meni) patrzy na system z punktu widzenia jego użycia, a programiści z punktu widzenia... frameworków? Języka? Czy czegoś podobnego. Mówiąc w skrócie biznes patrzy z zewnątrz do wewnątrz a programiści odwrotnie.
No więc Dan wpadł na pomysł, żeby zbliżyć te wizje do siebie przez zmuszenie programistów do tego, żeby myśleli po angielsku, a więc za pomocą rzeczowników i czasowników a nie instancji i metod. Konkretnie chodziło mu o to, żeby wyrażać testy jako przykłady (coding by example) wyrażane w języku naturalnym (angielskim, bo: primo - polska fleksja nie nadaje się do parsowania, secundo - Dan nie włada polszczyzną). Idealnie powinno być tak, że nieprogramiści (tak, to jednak pewnie grubo ponad 99% ludzkości) są w stanie to przeczytać i zrozumieć. Tu wchodzimy na grząski grunt DSLi, którymi nie chcę się dziś zajmować, bo jest późno, a i tak już dużo napisałem.
Wracając do tematu, Dan wymyślił dość zwięzły i krótki zapis, który jest zrozumiały dla innych (no..., że nie tylko dla nas), a przy okazji jest parsowalny i da się przerobić łatwo na coś zrozumiałego dla maszyn. Zapis Dana jest następujący (ukradłem ten tekst ze strony Dana, więc mu nie mówcie):

Title (one line describing the story)

Narrative:

As a [role]

I want [feature]

So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title

Given [context]

And [some more context]...

When [event]

Then [outcome]

And [another outcome]...

Scenario 2: ...

Story to coś a'la User Story w zwinnych metodykach, czyli jakaś funcjonalność. Narrative to znów znany ze zwinnych metodyk zwrocik (oj, zdrobnienie - wyszło, żem Warszawiak) "Jako KTOŚTAM chciałbym COŚTAM żeby COŚ SIĘ STAŁO". Do tego dochodzi Scenario, czyli konkretny przykład stosowania funkcjonalności, w formie znanej z wykładów Szczepana Fabera:

Given ...
When ...
Then ...

Czyli prosty zapis tego co dane jest na wejściu, operacji, i jej wyniku.
Takie zdania powinien być w stanie nam dostarczyć każdy analityk (no dobra, tak naprawdę, to biznes powinien siedzieć nad tym z programistą, w końcu customer on-site...) A my z tych zdań budujemy szybko sobie testy, które prowadzą (młodzież powiedziałaby drajwują, ale ja jestem stary) zarówno zakres funkcjonalny tworzonej aplikacji, jak i w pewnym stopniu design - przynajmniej API.

Podsumowując - chodzi o to, by mieć wspólny zapis dla przykładów, które prowadzą development, oraz by te przykłady były wybierane (przez biznes) na podstawie ich wartości dla systemu. Realizacja tego pomysłu powoduje, że cały development jest prowadzony de facto przez interfejsy użytkownika, bo to jest to, o czym biznes myśli i co jest sobie w stanie wyobrazić (i dobrze!)

Do tego w BDD jest cała podszewka lingwistyczno-psychologiczna (powinienem pojechać tu hipotezą Sapir'a-Whorf'a ale na to jest zdecydowanie za późno....), która mówi o tym, że programiści lepiej myślą o kodzie jeśli rozumieją i wyrażają go po ludzku.

No i na koniec wisienka na torcie: oczywiście przykłady to tak naprawdę testy. Same przykłady to już dużo, bo pozwalają myśleć o kodzie z punktu widzenia jego użycia. Ale skoro przykłady opracowuje się na początku - przed pisaniem kodu, to chyba jest jasne, że nie wyrazić ich w postaci testów było by głupotą. No więc w ten sposób przykłady zachowań z BDD stykają się z testami akceptacyjnymi, prowadząc do A-TDD (Acceptance-Test Driven Development).

No, to chyba tyle. To teraz jak to się ma do Tumbler'a?
Jak już wiemy o co chodzi, to Tumbler po prostu realizuje tę ideę i trochę ją rozszerza (cóż - jestem przekonany, że Dan nie wymyślił tego po ubarwionej zielskiem wycieczce po Camden Town, tylko faktycznie miał to na myśli). Nie tylko pozwala on przekształcać pełnotekstowe przykłady/scenariusze (o składni +/- takiej jak powyższa) na testy JUnit'owe, ale generuje również raporty (aktualnie txt oraz html) z tego co przechodzi, co nie, a co jeszcze nie zostało zaimplementowane. To już dużo. Jednak główną myślą, która mi przyświecała przy tworzeniu tego narzędzia było, że większość programistów nie ma planu co ma zrealizować, tylko pisze co im się akurat wydaje w danym momencie ważne. Tak powstają nie tylko potwory i spółka, ale również po prostu niekompletne implementacje. A gdyby tak zastanowić się chwilę nad każdą funkcjonalnością, zapisać ją w formie przykładów i dopiero potem zrealizować? Dam głowę, że tak napisany kod nie powodowałby u autora myśli "gdybym tylko mógł napisać to jeszcze raz!" - bo raz piszemy to najpierw w głowie w przykładach, a potem przelewamy na papier - tfu, klawiaturę - w dopracowanej formie.

PS. Tumbler z troszkę zmienionym API oraz nowymi funkcjonalnościami wyjdzie w ten weekend, więc kto żyw ściągać w poniedziałek rano i stosować! ;-)

Agile Warsaw

2010-05-12T13:56:00.000+02:00

Miło mi poinformować, że założona została grupa Agile Warsaw, która ma na celu stworzenie w Warszawie społeczności ludzi związanych ze zwinnym wytwarzaniem oprogramowania. Chcielibyśmy utworzyć przestrzeń z klimatem wzajemnego uczenia się, wymiany doświadczeń, wspólnego szukania nowych dróg do lepszego tworzenia oprogramowania, prowadzenia zespołów i zaspokajania potrzeb naszych klientów. Chcielibyśmy by to środowisko samo było zwinne, dlatego szczególną wagę przykładać będziemy do prostoty, komunikacji, informacji zwrotnej, odwagi i szacunku. Jeśli więc starasz się realizować te wartości w swojej pracy, chciałbyś dowiedzieć się jak pracują inni i dzielić się swoimi zwinnymi doświadczeniami - jesteś więcej niż mile widziany.
Spotkania planowane są w wybrane poniedziałki, o godzinie 19stej w siedzibie firmy Aenima, ul Łucka 15 pok. 227. Planowana formuły spotkań to mini-wykład (15-30min) po którym następuje dyskusja i wymiana doświadczeń, oraz Open Space Technology. Spotkania kończą się retrospektywą / socjalizacją / networkingiem w okolicznym pubie.

Najbliższe spotkanie odbędzie się 24tego maja, tematem przewodnim będzie przejście ze Scruma do Kanabana, a poprowadzi go Marek Kirejczyk.

Agile Warsaw ma też swoje miejsce w internecie - jest to googlowa grupa agile-warsaw.

Zapraszamy!

Płynne interfejsy

2010-05-06T01:07:00.000+02:00

Ten post powstał na wyraźną prośbę Jacka Laskowskiego i Bartka Zdanowskiego, którzy zastanawiali się (w komentarzach poprzedniego posta) nad kawałkiem przykładu z dokumentacji Tumbler'a. Przykład wygląda tak:

Zaciekawiła ich konkretnie linijka

library.lend(sampleBook).to(reader);

No i faktycznie, nie dziwię się, że ich zaciekawiła, bo nie jest to wyrażenie typowe dla Javy. Napisałem je w dokumentacji dość bezmyślnie, po prostu tak myślałem o tym kawałku kodu. To bardzo czytelne i jasne wyrażenie. Z drugiej strony jest ono dość trudne do zrealizowania i jego implementacja może sama nie być już taka czytelna, głównie dlatego, że logika pożyczania książki musi być wywołana w metodzie to a nie lend.

Ale zacznijmy od początku. Płynne interfejsy (fluent interfaces) to technika skupiająca się na takim zaprojektowaniu klas, by możliwe było ich wywoływanie w możliwie najczytelniejszy sposób. Żeby czytało się je prawie jak zwykłe zdania (to jest łatwiejsze w językach o elastyczniejszej składni jak ruby, groovy czy scala - w javie składnia jest bardzo sztywna). Powyższy przykład dość dobrze to obrazuje. W prostym przypadku płynny interfejs to tylko ciąg metod z których każda zwraca this. Tak na przykład tworzy się builder'y:

new Person()
.withName("Paweł")
.withHeight(178)
.withBirthdayOn(OCTOBER, 23);

Takie podejście pozwala obejść problem istnienia wielu różnych konstruktorów dla różnych wersji parametrów. Co więcej pozwala rozwijać klasę (dodawać nowe pola) bez zmiany dotychczasowego kodu. Ryzyko tylko jest takie, że możemy w jakichś metodach bazować na nowo dodanych polach, ale od czego są testy ;-)
Problem z płynnymi interfejsami jest taki, że języki umożliwiające wyłącznie statyczne definiowanie metod raczej wspierają bardziej 'funkcyjne' podejście, gdzie metoda to funkcja operująca na swoich (pewnie paru) parametrach. W przypadku płynnych interfejsów na wykonanie jednej funkcji składa się często parę wywołań metod, z których więkość tylko zmienia stan (magiczne słowo) obiektu/wywołania a dopiero ostatnia w łańcuchu (method chaining) faktycznie wykonuje jakąś operację. W powyższym przykładzie więc metoda lend wyłącznie ustawi w jakimś polu klasy library sampleBook, które będzie użyte potem w metodzie to jako parametr dla faktycznej operacji pożyczenia książki.

No dobra, ale metoda o nazwie to może pewnie obsługiwać dużo wiecej operacji - np:

library.send(someBook).to(emailAddress);

albo

library.move(otherBook).to(poetryShelf);

Jak obsłużyć takie sytuacje?
Najprostsze rozwiązanie to przeciążenie metody to. W zależności od typu parametru będziemy wywoływać tak naprawdę różne to, dzięki czemu możemy oddzielić ładnie te operacje.

No dobra, wcale nie ładnie - nazwa metody to nic nam nie mówi o tym co ta metoda naprawdę będzie robić, więc rozróżnianie jej typem parametru zmniejsza tylko czytelność tego kodu. Trochę lepszym rozwiązaniem jest delegacja z metody to do jakiejś metody o nazwie konkretnie definiującej funkcjonalność (np. przez doSend(someBook, emailAddress)). To trochę lepsze rozwiązanie, ale dalej niewiele daje czytelnikowi API. Posiadanie w klasie library trzech różnych metod to nie jest czystym rozwiązaniem tego problemu. Tak czy siak pierwsza implementacja naszej biblioteki wygląda następująco:

Metoda to powinna mieć jeszcze weryfikację stanu - nie można wywołać jej samej, bo to nie ma sensu. Dorzucę więc zaraz walidację stanu (sprawdzenie czy ustawiona została operacja).
Sam kod zbyt śliczny nie jest - już na pierwszy rzut oka widać, że metoda to będzie puchła - przyda się zatem mały refactoring:

No, teraz dużo lepiej. Metoda to jest już dość abstrakcyjna - jedyne co robi to weryfikacja stanu (czy może być wywołana), dodanie jej parametru (celu operacji) i wywołanie odpowiedniej metody. Nie mamy warunków, a cała logika odpowiedzialna za operacje jest w podklasach operacji (tu magia enumów, ale można było zastosować oczywiście klasyczną strategię). Teraz dodanie kolejnych metod to (dla innych parametrów) oraz innych podobnych metod będzie tylko podobną delegacją do odpowiedniej logiki. Będzie jasne jak i gdzie je dodawać. Jestem zadowolony.

Ale zaraz, powiedziałby Bartek Zdanowski, a co z równoległym dostępem do klasy library?
Hm, no to nie takie trudne chyba. Wystarczy wsadzić operację i parametry do ThreadLocal'a i tak operować na nich. Spróbujmy (klasę Operations sie nie zmieniła, więc skonwertowałem ją do top-level i jej nie widać, za to widać resztę):

Jak widać specjalnie nam to kodu nie skomplikowało, a mamy pewny równoległy dostęp. Dorzuciłem przy okazji czyszczenie stanu wywołania, tak, żeby następujące po sobie wywołania na pewno nie miały na siebie wpływu.

Jak widać płynne interfejsy nie są takie straszne, za to mają ogromny wpływ na czytelność kodu. Tak jak każdej innej techniki nie ma ich co nadużywać, ale w przypadku często używanego i/lub złożonego API są one bardzo przydatne. W bardziej skomplikowanych przypadkach może się okazać, że będziemy musieli wprowadzić wzorzec state by ładnie obsługiwać różne stany obiektu, choć zwykle jeśli to jest niezbędne warto się zastanowić, czy nasza klasa nie zaczyna odbiegać trochę od swojej głównej funkcjonalności.

Tumbler

2010-04-29T21:45:00.000+02:00

To, że jestem fanem TDD wie pewnie każdy kto czyta ten blog. Za szczególnie dobrą jego formę uznaję BDD. W kodzie, który powstaje u nas w firmie staramy się stosować to podejście - nazewnictwo wyrażające intencję twórcy, testy pisane w formie przykładów (często z wykorzystaniem promowanego przez Szczepana Fabera szablonu //given //when //then), skupienie na celu powstawania kodu. Niedawno do naszego zespołu projektowego dołączyli nowi programiści (pracownicy naszego klienta) nieposiadający doświadczenia w TDD. Pierwsze o co zapytali to szczegółowa dokumentacja kodu. Nasze przekonywanie, że testy są kompletne i dokładnie dokumentują kod nie spotkały się ze specjalnym zrozumieniem z ich strony ;-) Doszedłem więc do wniosku, że gdybyśmy mogli wygenerować z naszych testów dokumentację - nawet tylko w formie listy funkcjonalności oferowanych przez nasz kod - to pewnie ich opory byłyby znacząco mniejsze. A że akurat prowadziłem tygodniowe szkolenie poza Warszawą (miałem więc codziennie parę wolnych godzin po pracy), postanowiłem napisać narzędzie, które pomogłoby w tworzeniu testów tak, by:

jeszcze wyraźniej dawały znać co robią - tak, by nawet niewprawione w TDD oko rozpoznało o co chodzi (po prostu wystarczy czytać zdania...)
dawały się generować w formie specyfikacji
pozwalały lepiej myśleć o kodzie zanim jeszcze on powstanie (zapomniana faza 'think' z TDD) - w idealnym przypadku pozwalały na przygotowanie całego zbioru przykładów najpierw - np. wraz z kimś z biznesu, implementację pozostawiając na później (klasyczne Acceptance-Test Driven Development)
dawały aktualną informacje o stanie implementacji w formie raportu (które funkcjonalności jeszcze nie są zaimplementowane, które są i działają, które nie działają)
dawało się generować testy z pełnotekstowego opisu funkcjonalności
wspierały IDE tak, by było tam widać całe zdania opisu a nie nazwy metod testowych

Gdy wracałem ze szkolenia podstawowe funkcje były już prawie gotowe. Samolot nie odleciał (Eyafjoell...) więc miałem do tego 7 godzin w pociągu ;-) I tak powstał Tumbler - biblioteka wspomagająca myślenie o testach jako o przykładach, służąca do prowadzenia myślenia o tym CO zrobić a nie JAK. Nie będę tu duplikował dokumentacji, zainteresowanym polecam ją przejrzeć - nie jest tego dużo.

Chętnie wysłucham komentarzy i pomysłów co można by lepiej/bardziej/na dodatek.

Uczenie TDD

2010-04-20T18:41:00.000+02:00

Cały zeszły tydzień byłem we Wrocławiu i prowadziłem szkolenie a potem coaching w zakresie TDD. Przypomniałem tam sobie jak bardzo lubię uczyć ludzi TDD. To szczególny czas. Gdy zaczynamy szkolenie większość uczestników to całkiem przyzwoici programiści. Często z paroletnim doświadczeniem, paroma lub nawet paronastoma większymi lub mniejszymi projektami za sobą. Są wśród nich tacy, dla których programowanie to tylko praca, są też tacy, którzy spędzają tak każdą wolną chwilę. Są przekonani, że TDD to dobry pomysł, ale są też sceptycy przychodzący sprawdzić kto ma rację. Dzięki temu takie szkolenia to dla mnie wyzwania by spełnić wszystkich oczekiwania, wymagające kreatywności i dobrego przygotowania, pozwalające mi wciąż się uczyć i poprawiać swój warsztat. Szkolenia z TDD to jednak głównie okazja dla uczestników, by z dobrych programistów stać się świetnymi. To oczywiście nie staje się w dzień ani tydzień, ale takie szkolenie jest świetnym początkiem takiej zmiany.
Bardzo lubię patrzeć, jak umiejętności uczestników zmieniają się z ćwiczenia na ćwiczenie. Pierwszy dzień to zwykle poznanie nowych technik. Pierwsze próby myślenia "wspak" - od testów do implementacji. Powoli jednak okazuje się, że takie podejście ma swoje zalety. Najpierw uczestnicy dostrzegają jak wygodnie jest posiadanie testów przy refaktoryzacji. Później doceniają coding by example - myślenie o funkcjonalnościach w kontekście przykładów użycia kodu. Każde następne ćwiczenie idzie szybciej od poprzedniego, z większym skupieniem na tym o co kod ma robić a nie jak.
Fajnie jest patrzeć jak taki sposób tworzenia kodu, początkowo idący dość ciężko, pod koniec szkolenia nie sprawia już uczestnikom takich problemów, daje za to dużo satysfakcji. Patrzeć jak dużo można nauczyć się w tak krótkim czasie i o jak wiele można poprawić swój warsztat w ciągu tych paru dni. Dla mnie to przyjemne doświadczenie kontaktu z ludźmi, którzy chcą się uczyć i okazja do poprawiania umiejętności trenerskich. A na sam koniec to nieskromne uczucie zadowolenia gdy przeglądam wyniki ankiet od uczestników ;-)

Retrospektywa po AgileCE

2010-04-09T19:13:00.000+02:00

Pierwsze AgileCE jest już historią. Kto nie był, niech żałuje. Poziom merytoryczny tej konferencji był naprawdę wysoki. Ale po kolei.

Co się udało:

Świetne miejsce, idealnie dopasowane do liczby osób
Paul Klipp, organizator, reagował natychmiastowo i efektywnie na wszystkie niespodzianki
Były naprawdę ciekawe rozmowy kuluarowo-openspace'owe
Byli świetni prelegenci
Nie było tłumu
Kawa, ciasteczka i owoce dostępne cały czas
Spotkałem dużo interesujących ludzi, spędziłem masę czasu na rozmowach
Inicjatywa Agile Warsaw
Masa inspiracji i myśli
Świetne piwo w nocy

Co można poprawić w przyszłym roku:

inna restauracja na obiad dla prelegentów - czekanie 2.5 godziny na obiad i 1.5 na piwo to troszeczkę za dużo, ale może to jakaś Krakowska tradycja ;-)
openspace powinien być dodatkowo a nie w trakcie wykładów - ciężko zrezygnować z fajnego wykładu na rzecz fajnej rozmowy
może jeszcze parę osób ze stolicy by się wybrało?
poza proponowaniem hotelu można było znaleźć jakiś hostel w okolicy - nie każdy chce wydać na poleżenie w łóżku przez parę godzin więcej niż za dwudniową konferencję... można by wtedy wracać "w kupie" z nocnego piwa

A teraz na czym byłem:

Keynote w wykonaniu Rachel Davies
Rachel mówiła o ważności retrospektyw w życiu zespołu - ich wpływie na jakość produktów, motywację zespołu. Ważna rzecz dla nas: akcje z retrospektywy powinny mieć właściciela i ew. czas wykonania. Dzięki temu zespół o nich nie zapomni. Rachel mówiła też o wliczaniu akcji z retrospektyw do backlogu, by były widoczne i liczone do prędkości zespołu. Mówiła też o ich wycenianiu, ale to mnie nie przekonało - wiele z naszych akcji nie sposób wyrazić w żadnej mierze złożoności.
ScrumFluenca pana Jensa Korte. Jens przedstawił główne myśli i źródła, które wpłynęły na powstanie Scrum'a. Zrobił OGROMNĄ mapę zależności, która jest faktycznie bardzo ciekawa. Niestety Jens nie dał rady językowo i ciężko go było słuchać. No i może nie do końca dla mnie była ta prezentacja, bo trochę się znudziłem.
Monika Konieczny mówiła o ważności komunikacji w zespołach programistycznych. Brałem udział w symulacji pieczenia tortu z niejasnymi wymaganiami co faktycznie było fajne i w amerykańskim stylu prowadzenia prezentacji. Monika mówiła o altergames - grach symulacyjnych, które mogą pomóc zespołowi w zrozumieniu problemu. Ciekawe i przyjemne w słuchaniu. Szkoda, że Monika nie odniosła się do innych ruchów związanych z grami w światku agile'owym (np. agile fairytales).
Potem gadałem z Pawłem Brodzińskim w temacie agile: mindset or just a toolbox. Chyba nikt nikogo nie przekonał, ale przy okazji poruszyliśmy chyba z 20 innych tematów - było naprawdę ciekawie.
Ranek następnego dnia zajęła Zuzana Sochova z tematem kultury agile'owej w organizacjach, które tak tworzą oprogramowanie.
Potem głównie rozmawiałem na korytarzu i w openspace'sie o tworzeniu jakiejś inicjatywy zwinnej w Warszawie, Agile Coach Camp na który się wybieram na przełomie kwietnia i maja i parę innych tematów.
Ostatnim wykładem był The Sword and Other Tales w wykonaniu dwóch panów z Anglii, w czasie którego mówili o praktykach w radzeniu sobie z różnymi problemami u nich w zespole. Cała prezentacja była w stylu low-tech (slajdami były zdjęcia z obrazków na whiteboardzie). Panowie cały czas grali (w sensie teatralnym) i prezentacja była naprawdę wciągająca.

Całość oceniam zdecydowanie wysoko. Zarówno merytorycznie jak i organizacyjnie. Gratulacje dla organizatorów! Już czekam na przyszły rok.

AgileCE i ostatni tydzień rejestracji na szkolenie TDD

2010-04-05T20:01:00.000+02:00

Pod koniec tego tygodnia odbędzie się w Krakowie konferencja Agile Central Europe (w skrócie AgileCE). Będę miał przyjemność opowiedzieć tam przy okazji wykładu Being an agile nearshore team o tym jak budowaliśmy nasz zespół, wprowadzaliśmy zwinne praktyki, o zdarzeniach jakie mieliśmy w relacjach z klientem i jak sobie z nimi radziliśmy. Wszystkich zainteresowanych serdecznie zapraszam!

Ponadto rozpoczęliśmy właśnie ostatni tydzień przed zamknięciem rejestracji na szkolenie TDD. Wszystkich chętnych poznania technik związanych z tworzeniem oprogramowania przy pomocy testów zapraszamy. Gwarantujemy ogrom wiedzy i masę ćwiczeń!

Święta

2010-04-02T09:50:00.000+02:00

Na te wiosenne święta życzymy Wam wszystkim chwili rozkojarzenia i odpoczynku.

,`.
   ,'` | _.-.
   ,` | ,',' /
   : | ,',' ;
   \ : / / /
   \ `.' ( ,'
   ,'' _ `.
   ,' (o_) `\
  . (,.) _.-- :
-..`/( .-'_..- `|
.-'\,`. `-._ ;
   `._ /__
   ,':)-.._ _.(:::`.
   |'\ / /`:::|
   ,' \ : : : `:|
  / : | | | \
: | | : :..---.:
| | ; ,`._`-.|_ `.
| |' ,'._ `. `. |_\
| : /`-. `. `. `. :
: \ : __java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
`. `. `. \ ;at java.util.ArrayList.BunnyCheck
  \ \ |. / at javax.swing.AbstractBunny.fireActionPerformed
  |\ `.at javax.swing.plaf.basic.BunnyHandler.: `. __ \ \ /
  ' ` at java.awt.Component.processBunnyEvent .:::::\ `. / \ \,'
   .::::::::::-..'_..-'

Uuuups! Przepraszamy za królika. U nas działał. Widać trzeba go było jednak zrobić za pomocą TDD...

TDD interfejsu użytkownika

2010-03-27T14:23:00.000+01:00

29.03.2010 Zmieniłem trochę kod zgodnie z podpowiedzią Jakuba Nabrdalika, żeby zapisać to mockitową składnią BDD, oraz Michała Margiela, który znalazł duplikację w kodzie :-)

Pamiętam czas, kiedy miałem 19-20 lat. W ciągu dnia studia, wieczorami dla zabawy tłukłem oldskoolowe dos'owe wirusy i animacje fraktalne w asemblerze, a nad ranem i w weekendy zarabiałem, żeby było w tygodniu na obiady w 'Złotej Kurce' koło polibudy. Zarabiałem pisząc aplikacje w Delphi i C++ Builderze. To były narzędzia! Wystarczyło poukładać okienkowe komponenty na panelu i na każdym wykonać dwuklik. Od razu IDE przenosiło Cię do odpowiedniej metody gdzie wystarczyło napisać kod, który miał być wykonany gdy użytkownik kliknie w ten komponent. Ciągle się zastanawiam dlaczego mimo upływu 12 lat, środowiska Javowe nie pozwalają na to samo...
Ale wracając do tematu - za pomocą tych narzędzi: świetnego środowiska i tzw. Event-Driven Development stworzyłem parę... potworków. Dlaczego potworków? No więc pewnie dlatego, że moje doświadczenie programistyczne było małe i nie wiedziałem, że kod UI nie powinien być wymieszany z logiką. A już na pewno nie z kodem obsługi bazy danych...
W międzyczasie parę lat minęło i zdążyłem się zorientować, że są sposoby na pisanie kodu tak, by móc go zmienić bezpiecznie jakiś czas po napisaniu. Najpierw okazało się, że są wzorce projektowe, które dość skutecznie pomagają zaprojektować kod przed napisaniem. Dzięki temu dało się potem taki kod zmienić i poprawić. Niestety zwykle tylko raz, czasem dwa. Potem ten kod i tak stawał się do ... niczego nie podobny. Potem okazało się, że są testy jednostkowe, które pozwalają na utrzymywanie kodu w nieskończoność (o ile utrzymuje się też testy...) I tak doszedłem w końcu do mementu kiedy logikę miałem ujarzmioną testami, ale pozostawał interfejs użytkownika jako najsłabsze ogniwo. Tak mniej-więcej koło 2006 Martin Fowler napisał parę artykułów opisujących wzorce tworzenia UI (w szczególności chodzi mi tu o Passive View) i... sprawa stała się jasna :-)

W Pragmatists tworzymy oprogramowanie wyłącznie w TDD. Również interfejs użytkownika. Używamy więc wzorców przedstawionych przez Fowlera, ponieważ podstawowa ich zaleta to uniezależnienie logiki UI od widoku, więc idealnie nadają się do testowania. Nie zawsze jest to dokładnie to, co proponował Fowler, ale co do zasady jest to jakaś wersja wzorca Model-View-Presenter. Passive View polega na tym, że widok potrafi jedynie przekazać prezenterowi komunikat o tym, że zaistniało jakieś zdarzenie, oraz potrafi się odświeżyć na podstawie posiadanych przez siebie danych. Prezenter, po otrzymaniu komunikatu, że coś się w widoku zdarzyło, wykonuje odpowiednią operację na modelu i pobiera z niego dane. Następnie ustawia na widoku uaktualnione dane,a ten po zakończeniu działania prezentera, odświeża się. Widok jest zupełnie 'głupi' - bez jakiejkolwiek logiki poza wywoływaniem prezentera i własnym odświeżaniem się. Cała logika widoku jest w prezenterze, a model jest tak naprawdę Business Delegate'em do reszty aplikacji. Dzięki temu możemy odpuścić sobie testowanie view, bo ryzyko, że pomylimy się w jakimś getterze jest znikome ;-) Możemy dokładnie przetestować prezenter, włącznie z ew. przepływem między ekranami/panelami. A testy modelu to tak naprawdę testy funkcjonalne niższych warstw aplikacji.

Weźmy konkretny przykład. Załóżmy, że piszemy aplikację a'la kalendarz w Outlook'u i mamy ekran tworzenia nowego zdarzenia w kalendarzu. Takie zdarzenie ma zwykle nazwę, datę z godziną i listę zaproszonych osób. Chcielibyśmy móc takie zdarzenie zapisać, wybrać z książki adresowej osoby zaproszone, i wysłać zaproszenia do osób zainteresowanych. W zależności czy aplikację piszemy top-down (zaczynamy od UI idąc 'w głąb') czy mamy już gotową logikę (baza danych + wysyłanie zaproszeń), możemy zacząć albo od prezentera albo od modelu. Załóżmy więc, że zaczynamy od zera, więc jakiś grafik dłubie dżejpegi z ekranem nowego zdarzenia, a my w tym czasie robimy coś ciekawego :-)

Wiemy, że prezenter trzyma sobie model i widok (od razu je mockujemy - przecież ich nie ma, bo zaczynamy od prezentera), i potrafi zapisać zdarzenie (na podstawie danych z widoku, za pośrednictwem modelu):

@RunWith(MockitoJUnitRunner.class)
public class NewEventPresenterTest {
 @Mock
 private NewEventView view;
 
 @Mock
 private NewEventModel model;

 private NewEventPresenter presenter;

 
 @Before
 public void setUpPresenter() {
  presenter = new NewEventPresenter(model, view);
 }
 
 @Test
 public void shouldSaveEvent() throws Exception {
  //when
  presenter.saveEvent();
  
  //then
  verify(model).saveEvent(presenter.event);  
 }
}

No i taki test pozwala nam sprawdzić, że prezenter faktycznie zapisze reprezentowane przez view zdarzenie w modelu.

No to teraz użytkownik zmienia nazwę zdarzenia:

@Test
 public void shouldSetEventTitle() throws Exception {
  //given
  given(view.getTitle()).willReturn("test title");
  
  //when
  presenter.onTitleChanged();
  
  //then
  verify(view).getTitle();    
  assertEquals("test title", presenter.event.getTitle());
 }

Ustawia datę:

@Test
 public void shouldSetEventDateTime() throws Exception {
  //given
  given(view.getDateTime()).willReturn("2010-01-01 12:00");
  
  //when
  presenter.onDateTimeChanged();
  
  //then
  verify(view).getDateTime();    
  assertEquals(new LocalDateTime(2010,1,1,12,0), presenter.event.getDateTime());
 }

Pokazuje użytkownikowi listę osób, z których może wybrać kogoś do zaproszenia:

@Test
 public void shouldFillPotentialInvitees() throws Exception {
  //when
  presenter.onShowPotentialInvitees();
  
  //then
  verify(model).listPotentialInvitees();
  verify(view).setPotentialInvitees((Collection)anyObject());
 }

No i w końcu zaprasza wybrane osoby:

@Test
 public void shouldSetSelectedInvitees() throws Exception {
  //given
  given(view.getSelectedInvitees()).willReturn(Arrays.asList("friend1", "friend2"));
  
  //when
  presenter.onSelectedInvitees();
  
   //then
  verify(model).invitePeople(view.getSelectedInvitees());
  assertEquals(view.getSelectedInvitees(), presenter.event.getInvitedPeople()); 
 }

Do tego mamy oczywiście model, który wykonuje te wszystkie operacje. Najpierw tworzymy sobie zdarzenie (tu mockujemy dalszą warstwę, bo testujemy model):

@RunWith(MockitoJUnitRunner.class)
public class NewEventModelTest { 
 @Mock
 private EventService eventService;
 
 private Event sampleEvent;

 private NewEventModel eventModel;
 
 @Before
 public void initSampleEvent() {
  Collection friends = Arrays.asList("friend1","friend2");
  sampleEvent = new Event()
   .title("Test Event")
   .dateTime(new LocalDateTime()
    .withDate(2010, 10, 23)
    .withTime(0, 0, 0, 0))
   .invited(friends);
  when(eventService.fetchEvent((LocalDateTime)anyObject())).thenReturn(sampleEvent);
  when(eventService.fetchPotentialInvitees()).thenReturn(Arrays.asList("friend1", "friend2", "friend3"));
  
  eventModel = new NewEventModel(); 
  eventModel.setEventService(eventService);
 }

 @Test
 public void shouldCreateNewEvent() throws Exception {  
  assertNotNull(sampleEvent);
 }
}

Weryfikujemy warunki brzegowe:

@Test
 public void shouldNotSendInvitationsWhenNoEvent() throws Exception {
  //given  
  sampleEvent = null;
  
  //when
  eventModel.sendInvitations(sampleEvent);
  
  //then
  verifyZeroInteractions(eventService);
 }

 @Test
 public void shouldNotSendInvitationsWhenInviteesNull() throws Exception {
  //given  
  given(eventService.fetchEvent((LocalDateTime)anyObject())).willReturn(sampleEvent.invited(null));
  
  //when
  eventModel.sendInvitations(sampleEvent);
  
  //then
  verifyZeroInteractions(eventService);
 }
 
 @Test
 public void shouldNotSendInvitationsWhenInviteesEmpty() throws Exception {
  //given  
  given(eventService.fetchEvent((LocalDateTime)anyObject())).willReturn(sampleEvent.invited(new ArrayList()));
  
  //when
  eventModel.sendInvitations(sampleEvent);
  
  //then
  verifyZeroInteractions(eventService);
 }

Wyciągamy listę potencjalnych zaproszonych:

@Test
 public void shouldRetrievePossibleInvitees() throws Exception {
  //given  
  NewEventModel eventModel = new NewEventModel();  
  eventModel.setEventService(eventService);  
  
  //when
  Collection possibleInvitees = eventModel.listPotentialInvitees();
  
  //then
  assertNotNull(possibleInvitees);
  assertFalse(possibleInvitees.isEmpty());  
 }

W końcu wysyłamy zaproszenia:

@Test
 public void shouldSendInvitationsWhenInviteesNotEmpty() throws Exception {
  //when
  eventModel.sendInvitations(sampleEvent);
  
  //then
  verify(eventService).sendInvitations(sampleEvent.getInvitedPeople());
 }

I zapisujemy zdarzenie:

@Test
 public void shouldSaveEvent() throws Exception {
  //when
  eventModel.saveEvent(sampleEvent);
  
  //then
  assertSame(sampleEvent, eventService.fetchEvent(sampleEvent.getDateTime()));
 }

W ten sposób nie tylko mamy dobrze przetestowany zarówno prezenter jak i model, ale również mamy ładny w nich kod (czyż fluent interface klasy Event nie jest śliczny?) - a to dzięki temu, że zaczęliśmy pisanie tego kodu od jego użycia (testu = przykładu). Teraz tylko czas popoganiać grafika, żeby szybciej te pikselki układał i wybrać jakąś wygodną technologię do napisania widoku...

Ach, zapomniałem wkleić tu właściwy kod.... Ech, z resztą, ten to przecież teraz już każdy potrafi napisać, w końcu eclipse wygenerował sam przynajmniej z 30%...

*Autor posta dziękuje autorowi Mockito za to, że dzięki niemu w powyższych przykładach mockowanie jest tak proste, że prawie go nie widać :)

W TDD nie chodzi o testy

2010-03-22T23:32:00.000+01:00

W trakcie przygotowań do szkolenia z TDD:

K: Trzeba jakoś przekazać uczestnikom szkolenia, że w TDD nie chodzi o testowanie

M: Jak to nie chodzi o testowanie? To o co chodzi?

K: No chodzi o to, że testy są przykładami. Specyfikują to co właściwy kod ma robić.

M: No dobra, ale na koniec to i tak jest testowanie.

P: No tak, ale możliwość odpalenia testów i zweryfikowania poprawności kodu jest tylko efektem ubocznym. Podstawowym celem jest dobre zrozumienie problemu oraz utworzenie dobrego designu.

M: No tak, ale i tak testujemy a więc chodzi o testowanie
P: Racja, ale nawet gdybyśmy mieli po zakończeniu implementacji stracić związane z nią testy, to i tak byśmy chcieli je pisać. Po prostu wartość z dobrego zrozumienia implementowanego zagadnienia i poprawności designu jest już wystarczająca. Możliwość późniejszego przetestowania - safety net - jest tylko dodatkiem do podstawowej wartości.

Ta trwająca z 15min dyskusja dała mi chwilę do zastanowienia się o co tak naprawdę chodzi w TDD. I choć M ma rację, że piszemy testy - więc testujemy, to nazwy test oraz TDD są zdecydowanie mylące. Już napiszę dlaczego.

Tworzenie oprogramowania to bardzo skomplikowane zadanie. Wielu z nas doświadcza tego przy prawie każdym wdrożeniu. Albo (mam nadzieję) nawet wcześniej - jak tester dobiera się do aplikacji i znajduje w niej masę błędów. Skąd one się biorą? Oczywiście czasem jest to jakieś drobne lenistwo programistów, ale większość przypadków to niekompletne rozwiązanie jakiegoś problemu lub niezauważenie jakiejś możliwości przepływu w aplikacji. Czyli żeby takich błędów nie było, trzeba by zapewnić dwie rzeczy:

1) dobre i kompletne zrozumienie rozwiązywanego problemu przez programistę

2) zapewnienie poprawnego wykonania aplikacji dla dowolnych parametrów (dowolnego przepływu kontroli w kodzie)

TDD jest odpowiedzią na oba te problemy. Jeśli zaczynamy pisanie kodu od jego wyspecyfikowania, czyli podania przykładów jego użycia, nasze zrozumienie zarówno rozwiązywanego problemu jak i samego pisanego kodu jest dużo większe. Po prostu spędzamy więcej czasu na zastanawianiu się nad problemem oraz projektowaniem rozwiązania. Ze względu na to, że w TDD definiujemy przykłady wykorzystania implementowanego kodu, bardzo często TDD nazywa się kodowaniem przez przykłady (coding by example). Na niższym poziomie piszemy po prostu przykłady zachowań obiektów (czyli jak chcemy wykorzystywać kod obiektu z innego obiektu).

Powiedzmy więc, że chcemy napisać kod do obsługi pianina. Zaczynamy więc od reakcji na wciskanie klawiszy:

@Test
public void shouldPlaySoundWhenKeyPressed() {
// given
Piano piano = new Piano();

//when
piano.pressKey(Piano.Key.C);

//then
assertEquals(Piano.Key.C, piano.lastPlayedSound());
}
Na razie nic specjalnego. Teraz dodajemy pedał:

@Test
public void shouldPlayLongWhenSustainPedalPressed() {
// given
Piano piano = new Piano();

//when
piano.pressSustain();
piano.pressKey(Piano.Key.C);
waitFor(5).seconds();
piano.releaseSustain();

//then
assertEquals(5, piano.lastSound().lasted(seconds));
}
I już widzimy, że klasa piano wymaga refaktoryzacji, więc poprzedni test powinien mieć w assert:

piano.lastSound().value()

W ten sposób kształtujemy API tak jak najwygodniej bę

dzie nam go używać, wymuszając na implementacji właściwy design i poprawiając czytelność kodu (czy waitFor(5).seconds() nie jest czytelniejsze od try { Thread.sleep(5000); } catch (InterruptedException e) {}?). Poprawiamy też nasze zrozumienie problemu - zorientowaliśmy się, że dźwięk ma nie tylko wysokość, ale również długość trwania, więc odpowiednio zmieniliśmy design.

To, że prawdziwe TDD pozwala na zapewnienie poprawnego wykonania kodu dla dowolnych parametrów jest jasne... jak się wie co to jest prawdziwe TDD ;-) Tak jak definiował je Kent Beck i jak zwykło się go nauczać, krok implementowania testu realizuje się przez napisanie najprostszego kodu, który powoduje, że test przechodzi. Jak najbardziej "po bożemu" jest więc pisanie trywialnego kodu po to tylko, żeby na drodze małych kroczków wymusić w kodzie istnienie wyłącznie tego, co jest wymagane i przetestowane. Tak więc dla powyższego przykładu, pierwsza implementacja metody pressKey wyglądałaby tak:

public Key lastPlayedSound() {
return Key.C;
}

Do przejścia testu wystarczy, a powoduje, że na pewno nie napiszemy żadnego kodu niepokrytego testami. Właściwa, kompletna implementacja powstanie już pewnie w ciągu następnych minut. Po napisaniu podobnego testu z inną nutą ten test już nie przejdzie i będzie trzeba napisać pełniejsze rozwiązanie. Choć na pierwszy rzut oka takie podejście wydaje się naiwne i bezsensowne, pomaga ono spojrzeć na problem z punktu widzenia zasady YAGNI - implementujemy wyłącznie to, czego wymaga od nas specyfikacja - czyli testy. W ten sposób łatwiej nam wpaść na prostsze rozwiązania.

TDD to więc prowadzenie naszego rozumowania i rozumienia problemu. To tworzenie sobie w głowie modelu implementowanej dziedziny. To również sposób na dbanie o jakość kodu z punktu widzenia design'u (czytelność, bo implementujemy tak jak chcemy wykorzystywać i na bieżąco refaktoryzujemy by nam jak najbardziej pasowało) oraz poprawności (prowadzenie przykładami wszystkich możliwych ścieżek wykonania kodu).
To, że za jakiś czas będziemy mogli spokojnie zmienić dowolną część tego kodu, pewni, że jeśli coś zepsujemy, to odpowiedni test nas o tym poinformuje, jest tylko efektem ubocznym. Miłym dodatkiem do poprawnego kodu. A mówili, że nie istnieje coś takiego jak darmowy lunch...

Testy end-to-end w TDD

2010-03-17T08:10:00.000+01:00

Steve Freeman i Nat Pryce napisali książkę, która wywołuje dużo poruszenia w światku wytwarzania oprogramowania. Growing Object-Oriented Software Guided by Tests jest oceniana jako unikalna - dotychczas takiej książki o TDD nie było. Moim zdaniem w całej dziedzinie tworzenia oprogramowania rzadko spotyka się książki tak praktyczne, z dużą ilością kodu i świetnym przedstawieniem toku myślenia autorów.

Lektura tej książki skłoniła też Jacka Laskowskiego do napisania (jak na razie) dwóch postów. Chciałbym tutaj skomentować jego wypowiedź z pierwszego z nich. Najpierw krótko sparafrazuję myśli Jacka, do których chciałbym się odnieść:

Jacek pisze, że dotychczas zakładał, że w TDD chodzi o testy jednostkowe, czyli testujące poszczególne klasy w izolacji.
Tymczasem zaskoczyło go proponowane w książce podejście, w którym rozpoczyna się tworzenie aplikacji od napisania przekrojowego testu dotyczącego jednej prostej funkcjonalności. Chodzi o wyspecyfikowanie zachowania aplikacji z uwzględnieniem jej wszystkich warstw, od interfejsu użytkownika do połączeń z zewnętrznymi systemami, zanim jeszcze powstała architektura aplikacji. Jacek zastanawia się, który zespół wytrzyma tworzenie takiego testu, kiedy nic jeszcze nie ma? Wymaga to dużej determinacji i zdyscyplinowania - rzadko spotykanych zalet zespołów programistycznych.

Co daje nam stosowanie podejścia Test Driven? Jedną z zalet jest szybkie pojawienie się informacji zwrotnych co do poprawności stworzonego przeze mnie kodu. Kiedy piszę test jednostkowy, uruchamiam go i widzę czerwony pasek jUnita, wiem, że mam coś do zrobienia. Po napisaniu implementacji zielony pasek mówi mi, że skończyłem, że ten kawałek kodu działa, i mogę zająć się refaktoryzacją. Dzięki temu pracuję szybko, bo nie muszę uruchamiać aplikacji po każdej zmianie (lub debuggera jeśli po wprowadzeniu 10 zmian uruchamiam aplikację i nie działa poprawnie).

Patrząc od strony tego doświadczenia, to jest szybkości i pewności tworzenia oprogramowania, dość naturalnym wydaje się chęć, aby tak pracować jak najczęściej. Powiedzmy, że stworzyłem test-first warstwę dostępu do danych dla pewnej funkcjonalności i tak samo warstwę domenową. Teraz chciałbym wiedzieć, czy będą poprawnie współpracowały. Piszę zatem test, który będzie testem integracyjnym, idącym przez te dwie warstwy. Wymusi on na mnie napisanie kodu łączącego ze sobą obiekty z tych dwóch warstw w odpowiedni sposób (wiring).

Idąc dalej: powiedzmy, że właśnie rozpoczynam tworzenie projektu i czeka mnie stworzenie jego początkowej architektury. Mając doświadczenie szybkiej i automatycznej informacji zwrotnej, uzyskiwanej dzięki testom pisanym przed implementacją, mogę chcieć uzyskać taki feedback także i w tym przypadku. W tym celu tworzę właśnie test czegoś, co twórcy książki nazwali The Walking Skeleton, czyli szkieletu wszystkich warstw aplikacji. Uruchamiam go i szybko mam informację zwrotną, czy moja infrastruktura jest już gotowa, czy może potrzebuję jeszcze dodatkowego kodu lub konfiguracji, aby aplikacja zaczęła działać.

Powyższe rozumowanie mam nadzieję pokazuje, dlaczego mógłbym chcieć tworzyć aplikację w sposób opisany przez autorów książki. Tym niemniej, nie znaczy to, że jest to jedyna możliwość w zakresie szeroko rozumianego nurtu TDD. Możliwości tworzenia aplikacji w sposób test-driven jest wiele. Programiści często wypracowują swój styl, a różnice mogą dotyczyć różnych aspektów, takich jak stosowanie testów akceptacyjnych, integracyjnych, używanie mocków, podejście do testowania interfejsu użytkownika.

Na przykład autorzy wzmiankowanej książki, Steve Freeman i Nat Pryce, stosują podejście do TDD, które można określić jako "Mockist approach", tzn. że mocki są podstawowym narzędziem w tworzeniu testów. Zainteresowanych dokładnym omówieniem różnic pomiędzy tym podejściem a podejściem klasycznym odsyłam do artykułu Martina Fowlera.

Co do pisania testów przekrojowych (end-to-end), to ja nie jestem ich zwolennikiem i zdecydowanie staram się ich unikać. Moim zdaniem testy jednostkowe plus trochę testów integracyjnych daje wystarczająco dużą pewność co do poprawności działania aplikacji. Wadą testów przekrojowych jest przede wszystkim ich powolność. Wyobrażam sobie, że mógłbym ich użyć do stworzenia architektury i być może zainspirowany książką spółki Freeman&Pryce spróbuję, jak taki sposób pracy "smakuje". Dotychczas używałem ich rzadko i raczej jako testy regresji, czy smoke testy - zgrubne sprawdzenie, czy nie popsuliśmy aplikacji.
Jeśli już używamy testów end-to-end, trzeba pamiętać o zachowaniu proporcji - zgodnie z piramidą testów tych przekrojowych powinno być jak najmniej.

Oficjalna strona szkolenia z TDD

2010-03-15T01:00:00.000+01:00

Powoli dopinamy kwestie organizacyjne związane ze szkoleniem Test-Driven Development. Zainteresowanych szczegółami odsyłam do oficjalnej strony szkolenia.
Polecam szybkie rejestrowanie się, ponieważ ze względu na to, że szkolenie będzie w formie warsztatów, liczba miejsc jest ograniczona!

Szkolenie Test-Driven Development

2010-03-04T22:55:00.000+01:00

Szkolenie ze Zwinnego Rozwijania Oprogramowania zostało dobrze przyjęte przez uczestników. Dało nam to dużo radości, satysfakcji, jak również motywacji do tego, aby kontynuować dzielenie się swoją wiedzą i umiejętnościami.

Tym razem chcemy przekazać wiedzę, która wydaje się nam, zespołowi Pragmatists, bardzo cenna. Test-Driven Development, czyli sposób programowania, w którym zaczynamy od wyrażenia w kodzie naszych intencji, wywiera ogromny pozytywny wpływ na naszą pracę. Bezpieczniejsze, pewniejsze kodowanie. Rzadsze korzystanie z debuggera. Mniej defektów. Lepszy design. Czytelniejszy kod. Krótko mówiąc - zupełnie inaczej niż kiedyś i bardzo przyjemnie.

Zatem zapraszamy na szkolenie, gdzie podzielimy się naszym doświadczeniem ze stosowania TDD w prawdziwych, komercyjnych projektach. Adresowane jest do programistów i architektów (wymagana znajomość Javy). Możecie liczyć na solidną porcję wiedzy, ale przede wszystkim mnóstwo ćwiczeń, warsztatów, oglądania i pisania kodu. Czas trwania to 3 dni, od 19 do 21 kwietnia 2010. Więcej szczegółów zamieścimy już wkrótce.

Szkolenie poprowadzi wraz ze mną Michał Margiel, pasjonat Javy, współorganizator Javarsovii, codziennie test-drive'ujący mnóstwo dobrego kodu.

Poniżej treści, które zamierzamy poruszyć, a większość z nich także przećwiczyć praktycznie podczas warsztatów.

Wprowadzenie do TDD

czym jest TDD (cykl Red-Green-Refactor, porównanie do test-last)
korzyści ze stosowania TDD
TDD a projektowanie (design)
TDD a BDD (Behaviour-Driven Design)
rodzaje i poziomy testów: jednostkowe, integracyjne, akceptacyjne itp.

Mechanika TDD

wprowadzenie do JUnit
nazewnictwo testów
wsparcie przez IDE (integracja z JUnit, automatyczne refaktoryzacje, skróty klawiaturowe)
dyscyplina i rytm
mocki (Mock Objects)

tworzenie ręczne
frameworki (szczególny nacisk na Mockito)
inne rodzaje zaślepek (Test Doubles)

Projektowanie obiektowe

projektowanie pod kątem testów (Testability)
zasady wspierające dobry design (SOLID principles, Inversion of Control/Dependency Injection, powiązania, spójność)

Pokonywanie przeszkód

tworzenie test-driven warstwy dostępu do danych
tworzenie test-driven interfejsu użytkownika (GUI)

Praca z odziedziczonym kodem (Legacy Code)

jak pracować bezpiecznie (testy charakteryzacyjne, zmienne ułatwiające śledzenie)
techniki rozcinania zależności (dependency breaking)
identyfikacja punktów newralgicznych

Gdzie iść dalej

utrzymywanie testów
różne podejścia (BDD, ATDD, podejście klasyczne, podejście mockowe)
programowanie w parach
pokrycie kodu testami (code coverage)
wprowadzanie TDD w zespole

Nie każdy chce pracować w zwinnym zespole?

2010-01-07T17:20:00.000+01:00

W komentarzu do mojego posta o zwinnym szkoleniu Jacek Zawłocki napisał:

Ja w swojej naiwności sądziłem że wszyscy programiści pragną być członkiem zespołu Agile, tylko kierownictwo uważa Agile i programowanie w parach za fanaberię, hamując w rezultacie zapędy programistów. Jednak tak nie jest, co mnie bardzo zaskoczyło. Sami programiści nie wierzą, że to działa.

I faktycznie Jacek ma rację. Z czego to wynika?

1. Świadomość czym jest zwinność
Wielu programistów "naturalnie" skupia się na procesach, procedurach, praktykach. Codziennie nimi właśnie się zajmujemy. Je tworzymy w oprogramowaniu. Do ich stosowania jesteśmy przyzwyczajeni. Trudno jest więc przyjąć, że są one tylko środkiem a nie celem.
W zwinnych metodykach podkreśla się adaptacyjność - celem jest tworzenie wartości i dostarczanie jej często. Jak to robimy jest zależne od zespołu i warunków. Nie ma więc raczej uniwersalnych praktyk. Nawet iteracyjność, która jest często utożsamiana ze zwinnością, nie jest zawsze nieodzowna (np. Kanban nie jest iteracyjny - skupia się na równomiernym przepływie).

2. U nas się nie da ...
Wielu programistów dochodzi do wniosku, że nie mogą pracować zwinnie / że ich zespół nie może być zwinny, bo ich manager nigdy nie zgodzi się na ... (tu można wstawić cokolwiek: TDD, refaktoryzację, programowanie w parach, itp.) I to może być nawet prawda. Ale zwinny zespół to ten, który dostosowuje się do warunków. Jeśli nie da się robić TDD ("od testów mamy dział testów") to tego nie róbcie. Starajcie się inaczej dbać o jakość. Skupcie się na tym co można, co się da robić, a nie na tym czego się nie da. Jeśli można spotkać się z klientem/użytkownikiem co jakiś czas by pokazać mu aplikację i otrzymać komentarze - róbcie to. Jeśli można codziennie rano poświęcić 5min na ustalenie kto co zrobił i co planuje na dziś, warto to wprowadzić.

3. Przezroczystość
Praca w zwinnym zespole wymaga założenia, że mamy wspólny cel, i że realizujemy go razem. Dlatego chcemy wprowadzić maksymalną przezroczystość procesu i pracy, by każdy zawsze wiedział "gdzie jest" i by można było szybciej i odpowiedzialniej reagować na to co się dzieje w projekcie.
Nie każdy jednak chce by mu inni zaglądali w kod, by inni dokładnie wiedzieli co robi. Szczególnie osoby przyzwyczajone do pracy ściśle indywidualnej mogą mieć opory żeby poświęcić część swojej prywatności zawodowej (skądinąd czy to czasem nie jest oksymoron?)
W zwinnych zespołach zakładamy, że nic w pracy nie jest indywidualne - ani kod, ani czas pracy nie jest własnością programisty. Odpowiedzialność i uczciwość zawodowa, ale również prędkość pracy i zaufanie w zespole i klienta względem zespołu wymagają jawności.

Wierzę, że jeśli przyjmie się takie proaktywne, pozytywne nastawienie dużo łatwiej o zwinność.

Po Zwinnym Szkoleniu

2009-12-09T19:10:00.001+01:00

W ostatni piątek i sobotę prowadziliśmy szkolenie ze Zwinnego Rozwijania Oprogramowania.
Cel był dość prosty - przekazać w te dwa dni jak najwięcej wiedzy dotyczącej zwinnych metodyk i myślenia/filozofii z nimi związanej. Najważniejsze dla nas było zrobienie tego w taki sposób, który pozwoli kursantom zacząć wdrażać nowopozyskaną wiedzę już pierwszego dnia po szkoleniu. Opierało się więc ono w dużej mierze na warsztatach i ćwiczeniach.

Agenda szkolenia była następująca:
1) Wprowadzenie do Zwinnego Rozwijania Oprogramowania
Bazując na manifeście przekazaliśmy wszystkie główne myśli i zasady związane ze zwinnym myśleniem. Porównaliśmy zwinne metodyki z tradycyjnym "inżynierskim" podejściem. W ramach warsztatów pokazaliśmy, że zwinne metodyki dotykają wszystkich głównych problemów związanych z prowadzeniem i realizacją projektów programistycznych.
2) Scrum & eXtreme Programming
W tej części zaprezentowaliśmy dwie różne, ale zwykle używane komplementarnie zwinne metodyki: Scrum i XP. Staraliśmy się pokazać jak wypełniają one zasady zawarte w Manifeście. Przy okazji w ramach warsztatów z pomocą Scrum'a pisaliśmy wspólnie poezję :)
3) Zwinne praktyki programistyczne
Ta część przybliżyła założenia co do pisania oprogramowania związane z XP (TDD, programowanie w parach, Continous Integration), co to znaczy pisać Czysty Kod oraz opisała ideę Software Craftsmanship.
Krótki wykład zakończył się prezentacją połączenia TDD z programowaniem w parach (tzw. TDD ping-pong).
4) Zwinne Szacowanie i Planowanie
W ramach tej części pogłębiliśmy temat szacowania i planowania bazującego na Scenariuszach (User Stories), pokazaliśmy jak robić to w grupie (Planning Poker) oraz w jaki sposób wyceniać i planować iteracje i wydania. Nawiązaliśmy do tego jak mogą wyglądać umowy w zwinnych projektach i jak działać zwinnie w przypadku projektów fixed-time & fixed-scope. Pokazaliśmy jak liczyć prędkość zespołu i do czego można ją wykorzystać.
Zdobytą wiedzę wykorzystaliśmy do szacowania codziennych czynności takich jak pisanie smsów, czytanie książek czy wieszanie firanek :)
5) Zwinne zespoły
W tej części opowiadaliśmy o tym czym zwinne zespoły różnią się od zwykłych, co wpływa na efektywność pracy zespołu, co można zrobić, by zespół poprawiał jakość tak swoją jak i tworzonych przez siebie produktów. Pogłębiliśmy temat retrospektywy jako mechanizmu ułatwiającego zespołowi unaocznianie problemów i ciągłe poprawianie się. Na koniec przeprowadziliśmy warsztaty z prowadzenia retrospekcji.
6) XP Lego Game
Jako podsumowanie praktycznej części szkolenia zrealizowaliśmy kompletny projekt z wykorzystaniem planowania, szacowania i retrospekcji. Właściciel produktu weryfikował poprawność wykonania, wymagał refaktorowania części i dotrzymywania terminów. W ten sposób zrealizowaliśmy park z klocków lego:

7) Transformacja zespołów i organizacji
Ta, najbardziej teoretyczna część, dotyczyła wprowadzania zwinnych metodyk w istniejących zespołach, transformacji organizacji i sposobów pracy zwinnych zespołów z niezwinnymi działami. Dotknęliśmy zagadnień przekazywania odpowiedzialności i uprawnień związanych z projektem zespołom, roli menagera, lidera i coach'a w zwinnych zespołach.

Retrospektywa
Na koniec szkolenia poprosiliśmy kursantów o wypełnienie ankiety, na podstawie której wyciągnęliśmy następujące wnioski (z powtarzających się komentarzy i ocen każdej z części oddzielnie):

Co się udało:

szkolenie bardzo się podobało - 98% uczestników uważało je za bardzo dobre

dwóch prowadzących o różnych temperamentach i punktach widzenia poszerzało perspektywę (zostaliśmy nazwani "dobry i zły glina" ;-))

wprowadzenie praktycznych warsztatów było dobrym pomysłem

projekt parku z LEGO był hitem :)

zrównoważyliśmy teorię z praktyką - zadowolone były zarówno osoby chcące poznać podstawy teoretyczne (już pracujące w Scrumie), jak i osoby bardziej oczekujące praktycznych informacji (zadowolenie z warsztatów i prezentacji TDD)

wszystko było prawie idealnie na czas

Co warto poprawić na następny raz:

lokalizacja bliżej centrum

salka szkoleniowa mogłaby być trochę większa

prezentacja TDD mogłaby być nie na koniec dnia, byłaby okazja podyskutować

prezentacja TDD powinna skupić się albo na refaktoryzacji, albo na drive'owaniu nowego kodu żeby była czytelniejsza

część poświęcona transformacji powinna mieć przykłady z życia wzięte

Na początku przyszłego roku planujemy otwarte szkolenie-warsztaty z TDD, na które już teraz zapraszamy.

Jesteśmy gotowi powtórzyć Zwinne Szkolenie dla konkretnych zespołów (jako szkolenie zamknięte), oraz zachęcamy do zgłaszania swojego zainteresowania udziałem w kolejnym takim szkoleniu otwartym, które pewnie odbędzie się też w pierwszej części przyszłego roku.

Rekrutacja

2009-11-16T12:52:00.000+01:00

Rozpoczynamy oficjalną rekrutację do naszego zespołu. Szukamy ludzi, dla których tworzenie oprogramowania to pasja. Takich, którzy już umieją wiele ale chcą nauczyć się jeszcze więcej. Ludzi, którzy chcą i umieją pisać czysty kod. Którzy dbają o swoją pracę i zespół z którym pracują.

Oczekiwania:
- doskonała znajomość Java/JEE
- świetna znajomość kilku z javowych frameworków i bibliotek wykorzystywanych w aplikacjach klasy enterprise (takich jak Hibernate, Spring)
- umiejętność tworzenia aplikacji z grubym klientem (Swing)

Atuty dodatkowe:
- doświadczenie pracy w zwinnych metodykach
- TDD, refaktoryzacja, mockowanie, wzorce projektowe
- doświadczenie w tworzeniu aplikacji bazujących na NetBeans Platform

Gwarantujemy:
- pracę z bardzo dobrymi programistami w zgranym zespole
- pracę w zwinnych metodykach (eXtreme Programming / Scrum)
- pracę z kodem wysokiej jakości
Ponadto jesteśmy pewni, że już po paru tygodniach pracy z nami staniesz się jeszcze lepszym programistą i nauczysz się bardzo dużo.

Zainteresowanych prosimy o przesłanie swojego CV wraz z krótkim opisem dlaczego chciał(a)byś u nas pracować i dlaczego właśnie Ciebie mamy zaprosić do naszego zespołu na adres contact@pragmatists.pl

Zwinne szkolenie

2009-11-13T22:37:00.000+01:00

W dniach 4-5 grudnia organizujemy szkolenie: Zwinne Rozwijanie Oprogramowania (ang. Agile Software Development :)). Prowadzić będę je ja wraz z Krzyśkiem Jelskim.
Wszelkie szczegóły dotyczące szkolenia można uzyskać pod adresem http://pragmatists.pl/szkolenie.

W tej chwili mamy zarezerwowaną już ponad połowę miejsc.
Jako, że do końca rejestracji pozostał już tylko tydzień, zachęcamy do zgłaszania się!

Blog firmowy - Początek

2009-11-10T22:04:00.001+01:00

Niniejszym rozpoczynamy firmowy blog. Będzie czasem techniczny, czasem dotyczący tego, co robimy, co organizujemy, do czego dążymy.
Zapraszamy!