środa, 15 grudnia 2010

Nowe wyzwania -> poszukiwani nowi ludzie

W związku z tym, że pojawiają nam się nowe wyzwania, zaczynamy się rozglądać za chętnymi do pracy z nami. Szukamy ludzi, którym nie są obce i obojętne idee związane z Agile i Software Craftsmanship. Ludzi chcących pracować w małym samozarządzającym się zespole świetnych specjalistów. Oczekujemy wysokiego zaangażowania i dużej wiedzy. Najchętniej ludzi z jakimś doświadczeniem w TDD. Oczywiście java, jee, spring, hibernate, sql itp.
Chętnych proszę o mail pod contact@pragmatists.pl

środa, 17 listopada 2010

PowerMock

Powermock to narzędzie rozszerzające możliwości innych bibliotek do mockowania - Mockito i EasyMocka.
Nie jest to nowa biblioteka a jedynie kilka nowych funkcjonalności, które działają na dobrze znanym API.

PowerMock potrafi to, czego nie potrafią zwykłe biblioteki (te bez Powera w nazwie):
  1. mockować statyczne metody
  2. mockować klasy finalne
  3. mockować prywatne metody
  4. mockować konstruktory
  5. wyłączać zachowanie inicjalizatorów
  6. i parę innych rzeczy


1. Metody statyczne

Ortodoksi pewnie powiedzą "jeśli musisz mockować statyczne metody to prawdopodobnie masz zły design".
Każda aplikacja integruje się z różnymi zewnętrznymi bibliotekami i frameworkami. Jeśli framework z którego chcemy korzystać posiada API oparte na statycznych wywołaniach mamy dwie podstawowe opcje jeśli chodzi o testowanie:
  1. Stworzyć fasadę zewnętrznego API, która nie jest statyczna i którą łatwo wykorzystać we własnych testach.
    Plusy:
    • łatwo testować interakcje z zewnętrznym API
    • aplikacja nie jest zależna od zewnętrznego API i w razie potrzeby jego zmiany/wymiany wystarczy przepisać warstwę fasady

    Minusy:
    • Mamy dodatkową, może niepotrzebną z innych względów, warstwę, którą trzeba stworzyć i utrzymywać

  2. Użyć PowerMocka i bezpośrednio testować interakcję ze statycznym API. Na potrzeby testów nie wprowadzamy żadnych dodatkowych artefaktów do kodu.

Decyzję każdy musi podjąć samemu.

Zamockowanie statycznych metod wymaga jednej adnotacji nad testem
@PrepareForTest(UserManager.class)

oraz dwóch linii kodu w celu zadeklarowania zachowania:
PowerMockito.mockStatic(UserManager.class);
Mockito.when(UserManager.getCurrentUser()).thenReturn(admin);

Zweryfikowanie wywołania również wymaga dwóch linii kodu:
PowerMockito.verifyStatic();
NastyStatic.getCurrentUser();

Jest to trochę mniej wygodne i czytelne od zwykłego Mockitowego when() i verify().

2. Klasy finalne

Niemożliwość mockowania klas finalnych jest niewygodnym ograniczeniem Mockito. Jako że Powermock nie używa Proxies do klas tylko własnego classloadera - można to dzięki niemu osiągnąć.

3. Metody prywatne

PowerMock umożliwia również mockowanie prywatnych metod. Niestety tracimy tutaj wygodne API z Mockito, bo trzeba zdefiniować nazwę metody w parametrze. Zadeklarowanie zachowania prywatnej metody bezargumentowej wygląda np. tak:
doReturn("it's private").when(testedObject, "getPrivateString", new Object[0]);

a weryfikacja czy została zawołana
verifyPrivate(testedObject).invoke("getPrivateString", new Object[0]);

Osobiście nie podobają mi się takie konstrukcje w kodzie, dlatego też nie widzę tutaj żadnej wartości PowerMocka.

4. Konstruktory

Mockowanie konstrukcji obiektów jest dość ciekawym pomysłem.
Możemy dzięki niemu nawet zweryfikować ile obiektów danej klasy jest tworzonych:
PowerMockito.verifyNew(MyClass.class, times(10)).withNoArguments();

w tym przykładzie sprawdzamy, że zostało powołanych dokładnie 10 instancji klasy MyClass.


5. Wyłączanie fragmentów kodu

Wyłączanie inicjalizatorów i konstruktorów może być przydatne, gdy konstruktor nadklasy jest 'zły' i wykonuje jakieś akcje, które w teście rzucają wyjątek. Zgodnie z zasadą, aby nie wykonywać pracy w konstruktorze chcielibyśmy pominąć to zachowanie w naszych testach.
Do tego wystarczy przed powołaniem instancji tej klasy wykonać:
PowerMockito.suppress(PowerMockito.constructor(EvilClass.class));

spowoduje to również, że kod z bloku inicjalizującego się nie wykona.

możemy również wyłączyć wykonanie statycznego bloku inicjalizującego poprzez adnotację na klasie testu:
@SuppressStaticInitializationFor("com.evil.EvilClass")


Podsumowując:

PowerMock jest fajnym rozszerzeniem do Mockito czy EasyMocka. Może być przydatny tam, gdzie chcemy testować dobry kod, który musi być w interakcji z innym, trochę gorszym kodem. Warto rozważyć, czy to nie lepsze od pisania własnej fasady dostępu do zewnętrznego API.
Ponadto możliwość mockowania klas finalnych jest czymś, co umila życie nie prowadząc za sobą żadnych efektów ubocznych.

Szkolenie TDD - ostatnie miejsca

Nasze szkolenie TDD cieszy się dość dużym zainteresowaniem, więc ponad połowy miejsc już nie ma. Zainteresowanych zachęcam więc do szybkiej decyzji, tym bardziej, że zmiany VAT powodują, że od nowego roku szkolenia nie będą jak dotychczas zwolnione, lecz będą opodatkowane nową stawką 23%, co podniesie znacząco ich koszt.
O ile nie skończą się wolne miejsca, rejestrację zamykamy za 2 tygodnie.

wtorek, 2 listopada 2010

Nowa strona szkoleń & szkolenie TDD

Wystartowaliśmy z nową stroną dotyczącą prowadzonych przez nas szkoleń. Zawiera trochę więcej informacji o naszej ofercie szkoleniowej niż jej poprzednia wersja, poza tym wygląda "bardziej".

Poza tym startujemy z rejestracją na szkolenie TDD, które odbędzie się 6-8 grudnia. Można więc sobie zrobić miły prezent mikołajkowy :-) Szczegóły i rejestracja na stronie szkolenia. Zapraszamy!

Przy okazji chcemy poinformować, że Warsjawowy konkurs o miejscówkę na tym szkoleniu wygrał Jacek Złydach.

poniedziałek, 25 października 2010

Warsjawa

W ostatni weekend odbyła się konferencja warsjawa. Poza tym, że sposorując pomogliśmy w tym, by uczestnicy nie głodowali, mieliśmy też swój aktywniejszy udział. W związku z chorobą Sławka Sobótki zabawiłem uczestników rozważaniem nad Software Craftsmanship, jakością, dbaniem o zespoły i projekty. Slajdy z prezentacji dostępne są tu.
Na koniec prezentacji zrobiłem mały konkurs SMSowy w czasie którego można było wygrać wejściówkę na organizowane przez nas kolejne otwarte szkolenie z TDD. Pytanie konkursowe brzmiało: jak po japońsku (w kontekście agile/lean) brzmi słowo "doskonalenie"? Prawidłowa odpowiedź brzmi kaizen. W konkursie wzięło udział 30 osób, z czego równo połowa odpowiedziała poprawnie.
Co do szkolenia, szczegóły jeszcze w tym tygodniu.

wtorek, 5 października 2010

TDD - od czego zacząć?

W tym semestrze będę miał przyjemność uczyć Test-Driven Development na Uniwersytecie Warszawskim. W ramach przedmiotu Języki i narzędzia programowania III prowadzę grupę poświęconą TDD.

Ponieważ w tym tygodniu wyjeżdżam do Kijowa na konferencję Agile Eastern Europe, pierwsze zajęcia poprowadzę dopiero 14 października. Stąd pojawił się pomysł, aby przedstawić studentom kilka źródeł, dzięki którym mogą zacząć budować swoją wiedzę o TDD już teraz.

Żeby szybko zorientować się, czym jest TDD, dobrze jest zobaczyć, jak wykorzystuje tę technikę ktoś w niej biegły. Dlatego proponuję zacząć od Bowling Kata Roberta Martina (znanego też jako Uncle Bob). Jest to prezentacja, która krok po kroku przedstawia powstawanie programu do wyliczania punktacji gry w kręgle. Jeśli ktoś nie grał w kręgle i zasady punktacji są dla niego egzotyczne, może też obejrzeć w podobnym stylu zrobioną prostszą i krótszą Katę dotyczącą rozkładu liczby na czynniki pierwsze.

Po spotkaniu z praktyką można teraz uzupełnić wiedzę teoretyczną. Zostańmy przy Wujku Bobie i zobaczmy, co pisze o trzech regułach TDD. Ten artykuł pomoże nam zorientować się, o co chodzi w cyklu TDD. Zawiera także piękną wizję pokoju pełnego programistów, których cały kod minutę temu działał...

Jeśli ktoś chce pogłębić wiedzę o TDD w sposób bardziej usystematyzowany, warto sięgnąć do dostępnego w sieci bezpłatnie pełnego rozdziału książki Jamesa Shore'a The Art of Agile Development. Rozdział o prostym tytule Test-Driven Development zawiera wprowadzenie w tematykę na przykładzie programu do parsowania HTTP Query String.

Jeśli chodzi o materiały po polsku, nie jestem w stanie niestety zaproponować nic więcej niż podpowiada Google. Krótkie poszukiwanie ujawniło na przykład notkę w wikipedii i artykuł na podstawie wykładu Sabre.

Więcej uczymy się jednak robiąc, niż czytając, więc może czas na próbę zakodowania czegoś w TDD? Jeśli jeszcze nie czujesz się na siłach, obejrzyj jak robi to kolejny ekspert - Brett Schuchert. W serii filmów tworzy kalkulator działający w odwrotnej notacji polskiej.

Jeśli to za mało, to jako punkt wyjściowy do dalszych poszukiwań polecam blogi Object Mentorów, Uncle Boba, Nata Pryce'a czy też świetną serię artykułów The Craftsman (trzeba kliknąć w odpowiedni link)

piątek, 10 września 2010

I'm speaking at AgileEE

W tym roku, podobnie jak rok temu, będę miał przyjemność wystąpić na konferencji AgileEE. Jeśli ktoś więc nie miał okazji posłuchać o czystych testach na Javarsovii, zapraszam! 

AgileEE jest konferencją dotyczącą zwinnych metodyk i praktyk. W tym roku będzie tam cała masa świetnych mądrych prelegentów i znanych w zwinnym światku osobistości z całego świata, więc nie być to grzech.


wtorek, 7 września 2010

I po wakacjach

Trochę czasu minęło od ostatniego posta, a wydarzeń wartych opisania było parę. Oczywiście była Javarsovia. Największa Javowa konferencja w Polsce, a pewnie nawet jedna z większych w Europie. Javarsovia udała się w mojej ocenie bardzo - nie tylko dobór miejsca i sal był idealny dla tak wielkiego przedsięwzięcia, to jeszcze organizacyjnie 'live' wypadło świetnie.
Miałem przyjemność wystąpić tam z wykładem na temat utrzymywania testów w ładzie i czystości. Jeśli ktoś nie był, a chciałby przejrzeć slajdy (lub był i chce sobie odświeżyć) to są dostępne na stronie javarsovii tu. Może za jakiś czas pojawią się na stronie konferencji nagrania z prelekcji, to będzie widać jak dbam o czystość ;-)

W międzyczasie znalazłem też trochę czasu na Tumbler'a i wypuściłem wersję 0.3. Teraz obsługuje i17ę, poprawia współużycie w testach z Mockito, oraz dodałem słowa kluczowe And i But, co czasem poprawia czytelność. Głównie jednak zmiany dotyczyły wnętrza, ponieważ w ramach przygotowań do obsługi parametryzowanych testów (ale to jeszcze pieśń przyszłości) przepisałem parser na bardziej elastyczny, redukując przy okazji parę klas i usuwając parę powtórzeń.

Poza tym dość aktywnie zaczęła działać grupa Agile Warsaw. Bardzo mnie to cieszy, bo brakowało w Warszawie regularnych spotkań agile'owych. Wreszcie można nie tylko coś ciekawego usłyszeć, powiedzieć, ale również wypić piwo z interesującymi ludźmi :-) Polecam szczególnie tym, którzy jeszcze się nie zebrali żeby przyjść.

czwartek, 24 czerwca 2010

NYAC i Javarsovia

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!

poniedziałek, 24 maja 2010

Szkolenie TDD - retrospekcja

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ę!

środa, 19 maja 2010

Javarsovia 2010

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.

poniedziałek, 17 maja 2010

Tumbler 0.2.1

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

piątek, 14 maja 2010

Tumbler 0.2.0

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?
  1. 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ść.
  2. 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.
  3. 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)

czwartek, 13 maja 2010

Behaviour-Driven Development

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ć! ;-)