Refaktoryzacja w zielonym

Gdy prowadzę szkolenie z Test-Driven Development zwracam dużą uwagę na umiejętność refaktoryzacji kodu małymi krokami. Uważam, że to bardzo ważne, aby wiedzieć jak zmienić kod, nie rozwalając kompilacji ani testów. Stąd też zawsze znajduję czas na przynajmniej jedno ćwiczenie, w którym uczestnicy spróbują pracy w ten sposób.

Zazwyczaj robimy to z tym kodem, zmieniając wyjściową implementację do wzorca Strategii. Robimy to wg. mechaniki opisanej niegdyś przez Joshuę Kerievsky’ego. Przy okazji używamy maksymalnie dużo refaktoryzacji automatycznych w IntelliJ IDEA (lub Eclipse). Te 2 elementy – wykorzystanie IDE oraz małe kroki – sprawiają, że ćwiczenie bardzo się podoba.

Oczywiście można uczyć się refaktoryzacji „w zielonym” (zielony pasek runnera testów) także na innych przykładach. Ostatnio znalazłem na twardym dysku screencast, który zrobiłem kilka lat temu. Pokazuję w nim, jak za pomocą refaktoryzacji odkryć, że klasa ma za dużo odpowiedzialności (hint:Extract Till You Drop). Następnie dzielę ją na dwie mniejsze klasy, każda skoncentrowana na jednej odpowiedzialności.

Nagrywając ten screencast nie zauważyłem, że uruchomiam tylko 1 test, a nie wszystkie :-). Cóż, mylić się jest rzeczą ludzką. Tym niemniej sama refaktoryzacja jest ciekawa i zachęcam do obejrzenia.

Przy okazji zapraszam też na najbliższe otwarte szkolenie z Test-Driven Development. Będę je prowadził już 17 czerwca. Więcej szczegółów o tym, czego się spodziewać znajdziecie na tej stronie. Aby się zapisać, trzeba wypełnić ten formularz.

W filmie ukryłem też informację o tym, w jaki sposób uzyskać zniżkę na szkolenie. Zapraszam do oglądania!

by gaidaweb/Flickr https://www.flickr.com/photos/gaidaweb/4951145097

Specification by Example zmniejszy twoje historyjki

Lubisz duże historyjki użytkownika? Z rodzaju tych, które zajmują cały sprint? Ja ich nienawidzę.

Weźmy na przykład estymaty. Ja jestem słaby w estymowaniu i generalnie uważam to za trudną sztukę. Powiedzmy, że zespół właśnie dwukrotnie niedoszacował historyjki. Jeśli była mała, problem jest pomijalny. Ale jeśli była wielkości całego sprintu…

Albo integracja. Jeśli zespół nie używa Continuous Integration, to prawdopodobnie w przypadku dużej historyjki stworzy brancha, który będzie żył prawie cały sprint. Niedobrze, bo stracimy czas na jego integrację.

Jednym ze sposobów podzielenia dużej historyjki na mniejsze jest wykorzystanie Specyfikacji na Przykładach.  Zazwyczaj dzieje się to tak:

Najpierw czytam historyjkę użytkownika i zapisuję nazwy scenariuszy, które przychodzą mi do głowy. Powiedzmy, że jest ich 6.

Gdy je spisuję, to przychodzą mi do głowy kolejne. Pojawiają się myśli w rodzaju: „A co, jeśli zamówienie jest już zatwierdzone?” albo „Przecież wynik będzie zależał od roli użytkownika”. Zejście na poziom przykładów, wstawianie do nich konkretnych danych prowadzi do tego, że zauważamy pewne wzorce, zwracamy uwagę na różne zakresy danych, przychodzą nam do głowy połączenia nowej funkcjonalności z już istniejącą. Zatem naturalnie widzimy luki w specyfikacji i ją uzupełniamy. Po tym etapie dochodzą np. 4 kolejne scenariusze.

Teraz czas, aby mojej pracy przyjrzał się ktoś inny. Może tester, może ktoś z biznesu, może developer. Różni ludzie mają różne sposoby myślenia i zauważają inne rzeczy. W ten sposób pomagają zidentyfikować kolejne braki lub nieścisłości. Zatem pojawiają się, dajmy na to, kolejne 2 scenariusze.

No to mamy problem… Dla prostej historyjki, o której myśleliśmy, że zamknie się w 6 scenariuszach, okazało się, że jest ich 12. Na szczęście zrobiliśmy to przed implementacją. Jeszcze nie jest za późno, aby podzielić ją na mniejszą. W jaki sposób?

Przyglądamy się scenariuszom pod kątem tego, w czym są do siebie podobne, a czym się różnią.

Na przykład zauważamy, że w 3 scenariuszach użytkownik jest niezarejestrowany. Czy możemy najpierw zrobić funkcjonalność tylko dla niezarejestrowanych? Pewnie tak.

Dla innych 4 nie interesuje nas wartość zamówienia. Może zależną od niej funkcjonalność możemy zaimplementować później? Jasne, że tak.

Inne scenariusze mówią o walidacji. Czy możemy dostarczyć historyjkę bez walidacji, a tę wydzielić do nowej? Bardzo dobry pomysł.

Zatem, patrząc na podobieństwa i różnice między danymi w scenariuszach, dzielimy je na grupy nadające się do wydzielenia do oddzielnych historyjek.

Zauważ, że każda z wydzielonych historyjek przynosi jakąś wartość biznesową. Nawet, jeśli nie zdecydujesz się na jej wdrożenie na produkcję (a może jednak?…). Otóż uzyskujemy informacje zwrotne od naszych interesariuszy – właściciela produktu, klientów.


Jeśli temat wydał ci się interesujący, zapraszam na otwarte szkolenie z Specification by Example w dniach 24-25 listopada w Warszawie. Dzień pierwszy dla wszystkich zaangażowanych w wytwarzanie produktu, dzień drugi o automatyzacji dla osób technicznych.

Źródło zdjęcia: Flickr

Tradycje mockowe w Polsce

Wiedziałem, że tworzenie mocków to polska specjalność – w końcu to Szczepan Faber stworzył Mockito. Jednak podczas niedawnego wyjazdu na Podbeskidzie przekonałem się, że tradycje te musiały sięgać głębiej w przeszłość. Skoro ulicy nadaje się nazwę „Mocków”…  I tabliczka wygląda na całkiem wiekową.OLYMPUS DIGITAL CAMERA

 

Wygląda też na to, że tradycja jest podtrzymywana przez kolejne pokolenia. Nazwa ulicy się utrzymała i zasłużyła na nowoczesną tabliczkę.

OLYMPUS DIGITAL CAMERA

OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA

Skalowanie Scruma – po warszawskim BYOPie

Niedawno miałem przyjemność wziąć udział w pierwszym spotkaniu o intrygującej nazwie BYOP (czyt. bjop), czyli Bring Your Own Problem. Więcej o samej inicjatywie na stronie byop.pl.

Idąc na spotkanie nie miałem przygotowanego żadnego tematu, nastawiałem się raczej na słuchania i dzielenie się moim doświadczeniem. Atmosfera była jednak bardzo kameralna i pomyślałem, że może jednak…

Opowiedziałem o organizacji naszego zespołu – rozproszony i usiłujący robić Scruma – i o bolączkach wynikających z rozproszenia. Dostałem kilka cennych spostrzeżeń i porad.

Jak wygląda nasz zespół?

  1. Lokalizacja I – 4 bazodanowców, 1 javowiec/Scrum Master, Product Owner
  2. Lokalizacja II – 2 bazodanowców, 6 javowców
  3. Lokalizacja III – 2 testerów, menadżer
  4. Lokalizacja IV – 1 bazodanowiec

Ciekawym dla mnie doświadczeniem było to, że dopiero opowiadając o tym na BYOPie zdałem sobie sprawę ze stopnia rozproszenia zespołu. A także z jego wielkości (16 deweloperów).

Bolączki wynikające z takiego rozproszenia są dość naturalne

  • Trudności w komunikacji na spotkaniach. Zestawy konferencyjne może i sprawdzają się nieźle, jeśli po każdej ze stron są 2-3 osoby. Jeśli jednak jest ich więcej, to bardzo trudno śledzić zdalną dyskusję. Poza tym ze względu na słabość sprzętu, różnice w akcencie i w głośności mówienia, często po prostu się nie rozumiemy. Ze spotkania, gdzie koniecznie chcę zrozumieć co kto mówi, wychodzę z bólem głowy.
  • Dużo pracy solo. Słabo się znamy (część członków zespołu nigdy nie widziała się na żywo). Niektórzy często pracują z domu.
  • Nie wiemy, a często i nie interesuje nas, co robią członkowie zespołu w innych lokalizacjach.

Jak dotychczas sobie radziliśmy? Zaczynaliśmy od sytuacji takiej, że w lokalizacji I są tylko bazodanowcy, w lokalizacji II (czyli w Warszawie) tylko javowcy. Wtedy myśleliśmy o tym tak, że my tu w Warszawie jesteśmy zespołem Scrumowym i rozliczamy się tylko z zadań guiowych. Na dłuższą metę okazało się to oczywiście nieprawdą – dostarczanie funkcjonalności wymaga też pracy bazodanowców, a i z pracy i doświadczenia testerów warto by skorzystać. I tylko na tym poziomie – całego produktu i całego procesu – warto optymalizować. Mój kierunek działań przed BYOPem był taki, żeby dążyć do wspierania komunikacji pomiędzy różnymi lokalizacjami. Czyli chciałem budować jeden duży rozproszony Scrumowy zespół.

Teraz o tym, co usłyszałem na BYOPie.

Utworzenie feature teamów

Jednym z pomysłów na skalowanie Scruma jest dzielenie zespołu na mniejsze. Każdy z nowych zespołów powinien być Scrumowy w sensie posiadania pełni kompetencji do dostarczania funkcjonalności – nazywamy to feature teamem właśnie.

W naszym kontekście to, co się narzuca, to 2 zespoły w lokalizacjach I i II. Mimo dysproporcji java/db wydaje się to możliwe. Kwestia odpowiedniego doboru User Stories – tak, aby te, w których więcej jest pracy bazodanowej lądowały w lokalizacji I, a te bardziej guiowe w lokalizacji II.

Co ciekawe, gdy podzieliłem się tym pomysłem z kolegami, uświadomiliśmy sobie, że to już się dzieje. Mniej lub bardziej świadomie wybieramy takie User Stories, które jesteśmy w stanie realizować przy minimalnym wsparciu osób z innych lokalizacji. Niedawno też dowiedzieliśmy się, że kolega z lokalizacji IV opuści projekt. Decyzja menedżerów, może niekoniecznie wynikająca z opisywanych przeze mnie powodów, ale to krok w dobrym kierunku.

Jeden backlog projektowy, 2 sprint backlogi

Tu najbardziej podobało mi się uzasadnienie tego kroku, jakie dostałem na BYOPie. Wprowadzenie niezależnych sprint backlogów ma dać każdemu z feature teamów poczucie własnego celu.

Realizacja tego w naszym kontekście wydaje się trochę trudniejsza, przynajmniej formalnie. Nieformalnie zawsze możemy sobie zrobić sprint backlog na tablicy w naszym biurze. Ale żeby to działało, to reszta zespołu powinna być świadoma naszego sprint backlogu i wynikających z niego statystyk. Teraz naszą wspólną „tablicą” jest Rally. Czy pozwala na zamodelowanie 1 backlogu produktowego i 2 sprint backlogów – do sprawdzenia.

Wspólny sprint w jednym biurze 4 razy w roku

Nasze sprinty trwają 2 tygodnie. Co może dać realizacja sprintu w jednej lokalizacji? Poznanie innych członków zespołu jako ludzi. Poznanie ich kompetencji i sposobu pracy – czego możemy oczekiwać, w czym są dobrzy, gdzie możemy liczyć na ich pomoc. Zbudowanie zaufania.

4 razy do roku wydaje mi się kosmicznie trudne do zrealizowania w naszym kontekście. Ale 1 sprint w roku to cel, który wydaje się jak najbardziej osiągalny i w kierunku którego zamierzam działać.


Podsumowując, dostałem kilka cennych spostrzeżeń i rad. Myślę, że pozwolą nam bardziej świadomie „zarządzać” rozproszeniem. Co ciekawe, sam proces nazywania i opisywania innym tego, jak pracujemy, był bardzo cenny.

I jeszcze słowo o samej inicjatywie BYOP. Siłą tych spotkań jest to, że spotykają się tam osoby z różnych środowisk, z różnym doświadczeniem i pełniące różne role w organizacji. Dzięki temu możemy zyskać zupełnie nowe, niespodziewane spojrzenie na problem.

Agile Development Day – darmowe warsztaty Java/TDD/Agile

Moja firma rozpoczęła współpracę z Sages w zakresie szkoleń. Z tej okazji organizujemy jednodniowe, darmowe warsztaty – Agile Development Day. Całą sobotę, 10 grudnia, przeznaczymy na stworzenie podstawowej funkcjonalności aplikacji wspomagającej rozwój programistów.

Sam pomysł na aplikację, technologie, których zamierzamy użyć, i pomysł organizacyjny wydarzenia, sprawiają, że czekam na nie z niecierpliwością!

Więcej informacji i zapisy:

http://pragmatists.pl/agile-development-day-darmowe-warsztaty-agile-i-tdd

Wrażenia po Agile By Example

Hmm… już drugi raz zabieram się za spisywanie wrażeń po konferencji w jakiś czas po jej zakończeniu. Może następnym razem użyję twittera zamiast bloga, żeby wszystko było na bieżąco 😉

Agile By Example to pierwsza agile’owa konferencja w Warszawie. Konferencja bardzo udana. Chciałbymsię teraz skupić nie tyle na jej opisywaniu, co na konkretnych rzeczach, które z niej wyniosłem.

Wartości a praktyki

Jutta Eckstein mówiła o agile’owych praktykach w zespołach rozproszonych. Ważną myślą dla mnie było to, żeby pamiętać, jak praktyki mają się do celów i wartości. Otóż samo stosowanie praktyk nie sprawi, że wspólne cele czy pożądane wartości (agile’owe/XP) pojawią się w zespole. Jest tak, że to z wartości wypływają praktyki. Stosowanie praktyk może pomóc we wprowadzaniu tych wartości czy w ich podtrzymaniu, ale nie sprawi, że się pojawią. Jutta namawia, aby rozważając rozpoczęcie jakieś praktyki odnieść ją do celów i wartości zespołu. Czy cel praktyki jest również naszym celem? Czy ten cel wspiera nasze wartości?

W moim zespole jest tak, że prawdopodobnie mamy wspólne wartości i cele, ale nie jestem w stanie ich w sposób pewny nazwać (tzn. mogę zgadywać). Z tego wynika, że nasze wartości nie są uświadomione. Co mogłoby nam dać uświadomienie ich? Może chociażby lepsze zrozumienie tego, jak działamy, jak działają dla nas różne praktyki. Daje to właściwie gotowy pomysł na retrospekcję czy dzień budowania zespołu.

Testy jednostkowe budują zaufanie

Z prezentacji Jutty biorę jeszcze jedną zgrabną myśl: testy jednostkowe budują zaufanie. Przede wszystkim chodzi o zaufanie do kodu, co ma ogromne znaczenie w zespołach rozproszonych. Myślę jednak, że można to rozszerzyć na wzajemne zaufanie deweloperów. Ufam kolegom z zespołu, bo widziałem, że tworzą rzetelne, kompletne testy wokół swego kodu.
Znów, mogę zadać pytanie o to jak jest w moim zespole – czy testy, które mamy, budują zaufanie (do kodu, do nas samych)?

Ekstremalne zasady

W zespołach rozproszonych, które rozciągają się na kilka stref czasowych, nie można pozwolić sobie na przekazywanie kolegom niedziałającego kodu. Stąd Jutta przytacza dość rygorystyczne zasady proponowane przez Josepha Pelrine’a:

Na koniec dnia:

  • kod jest wczekinowany
  • testy są zielone
  • build przechodzi
  • build trwa poniżej 10 minut

albo wyrzucasz wszystko i wracasz do ostatniej wersji, gdzie te warunki były spełnione. 

Mocne? Co by się stało, gdyby Twój zespół wprowadził takie zasady?

Twórczość w projektach IT

Prezentacje Moniki Konieczny i Marcina Maciejewskiego przypomniały mi o temacie twórczości. Twórczość budzi we mnie skojarzenia z „Treningiem twórczego myślenia„, z używaniem mazaków, kredek i dużych kartek, z nieskrępowanym wypowiadaniem własnych pomysłów w bezpiecznym środowisku.

Co zrobię z tym? Na razie zamówiłem kilka książek, żeby sobie przypomnieć co nieco w tym temacie.

User Stories – problem a nie rozwiązanie

Bardzo spodobało mi się spojrzenie Moniki i Marcina na User Stories. Otóż Marcin jako Product Owner przynosi User Story do zespołu jako historię, w której występują konkretne postacie, mające prawdziwe problemy. Zespół konfrontowany jest z takimi problemami i to jego zadaniem jest wymyślenie rozwiązania.
To podejście jest inne od tego, co spotkałem dotychczas, gdzie User Story od Product Ownera przychodziło maksymalnie wyspecyfikowanie, często łącznie z projektem ekranów aplikacji.
Jeśli Product Owner jest sam, to korzystając z potencjału zespołu może dojść do znacznie lepszych rozwiązań. Być może nie jest to potrzebne, jeśli rolę Product Ownera wypełnia dedykowany zespół np. analityków. Ale z tym rozwiązaniem spotkałem się tylko w opowieściach…

Historie i metafory

Nie wiem, czy ktoś jeszcze pamięta o takiej praktyce Extreme Programming jak Metafora. Może wkrótce sobie przypomnimy, bo podobno Agile 2.0 to XP :-).
Mi się przypomniało, gdy Marcin opowiadał o swoich wysiłkach poszukiwania metafor przy tworzeniu User Stories. Czy nasz system wieloagentowy działa podobnie jak „rój pszczół zbierających pyłek”? Czy jeśli użytkownik może coś zrobić dokładnie raz i tylko raz, to jest to podobne do „spotkania opryszka w ciemnym zaułku„?
Przyznam, że nie miałem dotąd okazji pracować w projekcie, w którym pojawiłyby się metafory choćby o takiej mocy. Wyobrażam sobie, że mogą mieć duży wpływ na to, jak się myśli o domenie, jak się projektuje. Jaki jest pierwszy krok, żeby spróbować? Jeszcze nie wiem.

Czas iść dalej…

Jeszcze wiele ciekawych myśli zainspirowało mnie na tej konferencji. Nie będę się już o nich rozpisywał, ale wypunktuję kilka:

  • Kanban jako sposób zarządzania zmianą w zespole (Paweł Brodziński)
  • Sposób na ćwiczenie refaktoryzacji – robić przykłady z książki „Refaktoryzacja” lub „Refaktoryzacja do wzorców projektowych” (Alexandru Bolboaca)
  • Wartość testów akceptacyjnych – budowanie jednakowego zrozumienia domeny przez klienta i zespół (Szczepan Faber)
  • Single command environment – mogę jednym poleceniem odtworzyć całe środowisko deweloperskie (Szczepan Faber)
  • Rola managera w Scrumie: ustal ograniczenia i daj zespołowi to, co potrzebuje, by wykonać pracę. Nic więcej – nic mniej. (Boris Gloger)

Mam nadzieję, że za rok spotkamy się na równie ciekawej konferencji na tym samym basenie :-)

SC2011 – Wrażenia

Kilka wrażeń po konferencji Software Craftsmanship 2011.

How Object Oriented Are You Feeling Today?

Krzysztof Jelski

Najpierw o mojej sesji „How Object Oriented Are You Feeling Today?”. Przypomnę, że polegała na wykonaniu prostego zadania programistycznego przy stosowaniu się do 9 zasad, wymuszających obiektowość kodu:

  1. Use only one level of indentation per method
  2. Don’t use the else keyword
  3. Wrap all primitives and strings
  4. Use only one dot per line
  5. Don’t abbreviate
  6. Keep all entities small
  7. Don’t use any classes with more than two instance variables
  8. Use first-class collections
  9. Don’t use any getters/setters/properties

Pomysł na ćwiczenie zaczerpnąłem z eseju Jeffa Baya „Object Calisthenics”. Jako zadanie do rozwiązania wybrałem obsługę osobistego konta bankowego (wpłaty, wypłaty, saldo, wyciąg…).

Bardzo pozytywnie zaskoczył mnie poziom uczestników! Szacuję, że było ich około siedemdziesięciu. Wszyscy pracowali w parach i stosowali TDD. Większość programowała w Javie, kilka osób w C# i w Rubim.

Uczestnicy, od których dostałem informacje zwrotne, byli bardzo zadowoleni, jeśli programowali w Javie. Rubistom się nie podobało. Przyznaję, że nie próbowałem zrobić tego ćwiczenia w Rubim. Wyszedłem z założenia, że wyjdzie podobnie w dowolnym języku obiektowo zorientowanym. Wygląda jednak na to, że 9 zasad z „Object Calisthenics” z jakichś powodów nie pasuje do Rubiego. Chętnie kiedyś sam spróbuję.

Dla zainteresowanych przeprowadzeniem podobnej sesji link do slajdów.

Functional Programming

Micheal Feathers

Steve Freeman namówił Micheala Feathersa na poprowadzenie dodatkowej, nie ujętej w programie konferencji sesji. Była poświęcona programowaniu funkcyjnemu. Micheal pokazywał fragmenty kodu napisanego w stylu funkcyjnym, głównie w Rubim, jeden w Haskellu. Nie byłem świadomy, że Ruby ma zupełnie przyzwoite wsparcie do programowania funkcyjnego. Micheal nazwał moduł Enumerable „funkcyjnym DSL-em”.

Wywiązała się też ciekawa dyskusja na temat czytelności kodu. Gdy programujemy funkcyjnie, kod jest bardzo zwarty. Jednak czy jest czytelny, gdy np. zawiera dwie zagnieżdżone operacje map? Ciekawy kod, ciekawe dyskusje. Sesja zmotywowała mnie do poszerzenia mojej wiedzy o programowaniu funkcyjnym.

Lean Code Challange

Chris Parsons

Następna sesja, w której wziąłem udział, to Lean Code Challange, która prowadził Chris Parsons. Tworzyliśmy program, który działa „na kasie” i wylicza, ile klient ma zapłacić, uwzględniając m. in. aktualne promocje. Pracowaliśmy w parach (a ja nawet w trójce). Dowcip polegał na tym, że tworzyliśmy kod w 10-minutowych iteracjach, a rzeczywistość biznesowa zmieniała się z iteracji na iterację (a czasem nawet w trakcie). I tak np. wymaganie się pojawiało, by w następnej iteracji zniknąć; przy

kłady podawane przez klienta nie były kompletne.

Celem warsztatów było patrzenie na tworzenie kodu z perspektywy Lean, co dla mnie sprowadzało się do obserwowania, które elementy procesu są wasteem, czyli nie przynoszą wartości biznesowej. Przyznaję, że takich elementów w naszym procesie nie zauważyliśmy. Na pewno zaowocowało pisanie testów – kilka razy pozwoliły nam bezpiecznie zrobić spore zmiany w kodzie. Nie udało się nam ocenić refaktoryzacji – ze względu na presję czasu refaktoryzowaliśmy tylko wtedy, gdy skończyliśmy funkcjonalność, a został jeszcze czas do końca iteracji. Z punktu widzenia tego ćwiczenia trudno powiedzieć, czy to pomagało nam w przynoszeniu wartości klientowi.

Personal Codes of Conduct

Matt Williams

Tu już bez kodowania, tylko prezentacja i dyskusja. Matt mówił o osobistych kodeksach etycznych programistów. Wychodząc od kodeksu lekarskiego, szukał sposobów na stworzenie podobnych zasad w swojej praktyce programisty. Temat na czasie, co pokazuje choćby ukazanie się nowej książki Wujka Boba: The Clean Coder.

Podsumowując…

przyjemnością było dla mnie przebywanie w gronie pasjonatów tworzenia oprogramowania. Poprowadzenia własnej sesji dało mi dużo satysfakcji i wzmocnienia pewności siebie. No i Bletchley Park to wspaniałe miejsce na konferencję.

Moja sesja na Software Craftsmanship 2011

Wczoraj otrzymałem radosną wiadomość, że moja propozycja sesji na konferencję SC 2011 została przyjęta. Hura!

Sama konferencja jest dość ciekawa w swojej formule: wszystkie sesje muszą zawierać element pracy z kodem. Mogą to być gry lub wyzwania programistyczne, tutoriale, czy też sesje dzielenia się wiedzą i praktyką. Każde zgłoszenie musiało zawierać link do screencastu, przedstawiającego ideę sesji (mój film poniżej). Zresztą zerknijcie na opisy przyjętych sesji.

Więcej informacji o konferencji znajdziecie na jej oficjalnej stronie.

Po powrocie podzielę się wrażeniami na blogu, więc „stay tuned” :-)

[vimeogallery]

[/vimeogallery]

TDD z jMock2 – screencast Damiana Rodziewicza

Mockito święci tryumfy, ale warto spojrzeć też na inny, dojrzały framework do mockowania: jMock. Zwłaszcza, jeśli planujemy przeczytać książkę zwaną GOOS. W przykładach autorzy wykorzystują właśnie tę bibliotekę, którą zresztą aktywnie rozwijają.

Zapraszam do obejrzenia screencastu Damiana Rodziewicza, przybliżającego zastosowanie jMocka.

httpvh://www.youtube.com/watch?v=VHWX5aYM3hs