Warsjawa 2014 podsumowanie nr 2 i dawanie feeedback’u

W moim przedostatnim wpisie: Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty umieściłem materiały z których korzystałem podczas tych warsztatów i opisałem swoje pierwsze wrażenia. Teraz czas na kolejną ostatnią część podsumowania, ponieważ już jakiś czas temu spłynęły do mnie wyniki ankiety przeprowadzonej przez organizatorów. A jest się czym pochwalić :-D Poniżej zamieszczam fragmenty korespondencji, którą otrzymałem od organizatorów.

Odnośnie Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych

Your workshop was among best workshops of Warsjawa 2014! 

Here comes the results: 

number of feedbacks: 8 

average grade (1 to 5, higher is better): 4.63 

feedback comments: 

- A lot of knowledge presented, but a bit too fast. 

- Bardzo fajne i przydatne warsztaty - fajnie zorganizowane 

- Z warsztatów jestem bardzo zadowolony. Poznałem nowe, lepsze metody testowania, których mam nadzieje użyć w codziennej pracy. Projekt na githubie znacznie ułatwił cala sprawę. Dziękuje :) 

- Workshop was as described. From a begginer point of view approach : from simplest libraries to most helpful was realy good.

Co to dla mnie oznacza? Że dostałem 5 głosów z oceną 5 i 3 z oceną 4, lub jakiś inny wariant dający sumę 37. Przy ośmiu głosach daje to właśnie oceną 4.63 (a dokładniej 4.625). Bardzo się cieszę tak wysoką oceną, która w tym momencie trochę rekompensuje ogrom trudu włożonego w przygotowanie tegoż warsztatu.

Odnośnie Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Here comes the results: 

number of feedbacks: 6 

average grade (1 to 5, higher is better): 4.5 

feedback comments: 

- Prawdziwe warsztaty, bardzo ciekawie poprowadzone na konkretnym przykładzie. Nie mam do nich żadnych uwag. 

- Miałem iść na C/C++ in Android Apps. Jednak mnogość instalowania narzędzi zniechęciła mnie (była sobota 16:00)... dosłownie na 1 minutę przed startem warsztatu przyszedłem tutaj. I nie żałuje. Skrótów wszystkich nie zapamiętałem, ale wiem dokładnie co można za ich pomocą osiągnąć. Formuła warsztatu wymagała ciągłego zaangażowania oraz umożliwiała świetną zabawę w poprawienie kodu kogoś innego :) Prelegent bardzo pozytywnie nastawiony do życia i moim zdaniem niezły kozak jeżeli chodzi o Intelli :) 

- Very good workshop, I learned a lot about the Intellij Idea.

Tutaj ocena nie jest już tak wysoka, ale i tak jest dobrze. Zwłaszcza że warsztat był w sobotę pod koniec dnia i większość już pewnie myślała o wieczornym piwie. Bardzo mnie tutaj ucieszyła druga opisowa opinia jednego z uczestników. Dzięki - kimkolwiek jesteś.

Podczas analizowania feedbacku od uczestników moich warsztatów naszły mnie jednak smutne przemyślenia. Ludzie bardzo niechętnie dają opinię zwrotną drugiej osobie! Trzeba się o nią wręcz dopraszać i ciągnąć za język. Szkoda, że system głosowania na Warsjawie nie zadziałał, bo on mógłby dać trochę szerszy obraz oceny warsztatu. A tak, to ankietę pokonferencyjną – jak widać powyżej – mało komu chce się wypełnić. Nie wiem czy to wynika z naszej introwertycznej natury, nieśmiałości, poprawności politycznej, czy z problemu z wyrażaniem swoich odczuć? Przecież na co dzień przekzujemy dalej swoje opinie na temat kodu naszych współtowarzyszy projektu. Przecież robicie Code Review? A może nie?

W każdym bądź razie prelegenci, czy też prowadzący warsztaty – zwłaszcza Ci poczatkujący – oczekują jakiejś zwrotnej opinii na temat swojej pracy! Wierzę w możliwość ciągłego udoskonalenia się i poprawiania swoich zdolności, aby kolejnym razem wypaść lepiej.

W jaki sposób wiec najlepiej zbierać konstruktywne opinie o sobie i swojej pracy? Jak masz jakieś pomysły to koniecznie pisz w komentarzach!

Chcę jeszcze dokonać publicznej konstruktywnej samooceny (aby dać przykład, jakie potknięcia warto wytykać) i napisać, co poszło mi nie tak na moich warsztatach, aby następnym razem nie popełnić tego samego błędu. Na pierwszym warsztacie zapomniałem puścić powitalny filmiki od organizatorów. Niestety, ale tuż przed samymi warsztatami musiałem trochę pozmieniać bazę w git’cie (mam na myśli rebase, ale nie mam pojęcia jak to można na polski przetłumaczyć), aby historia na publicznym repo nie wyglądała później tak:

After reabse of 12 branches on master in #git pic.twitter.com/cQDWtdEtDJ
— Marcin Stachniuk (@MarcinStachniuk) September 22, 2014

Z tego względu gdzieś mi umknęła wiadomość od organizatorów, prosząca o puszczenie filmików. Sory!

Co do drugiego warsztatu, to trochę mniej się do niego przygotowałem (w sensie slajdów), ale na szczęście nie to było najważniejsze, co widać po ocenie. Ważne, że uczestnicy się świetnie bawili i wynieśli sporą wiedzę z warsztatu.

Błędem był jednak brak porządnej aplikacji na telefon / tablet, pokazującej odliczany czas i dającej sygnał dźwiękowy co określony interwał. W tym warsztacie było bardzo ważne, aby co 5 minut robić zmianę, ale mój budzik nie zawsze dzwonił, przez co niektórzy siedzieli dłużej przy klawiaturze. Jak ktoś ma godną polecenia aplikację, do tego na Androida, to czekam na info!

Również brak przerwy mniej więcej w połowie warsztatu był kiepskim pomysłem, gdyż to chyba szybko wymęczyło ludzi. W okolicach drugiej godziny, widziałem zmęczenie na twarzach uczestników. A przerwa tuż przed końcem warsztatów nie była wystarczająco odświeżająca.

Mogłem również się trochę lepiej przygotować z implementowanego problemu, aby w razie dojścia do ślepego zaułku (do którego doszliśmy), aby szybko z niego wyskoczyć na właściwe tory. Do poprawienia następnym razem.


Przy okazji konfitury, firma Spartez zorganizowała jeszcze konkurs dla uczestników. Zadania można było rozwiązać wcześniej online, aby nie tracić czasu na samej konferencji. Jak zobaczyłem pytania (a było ich 6), od razu wiedziałem kto wygra – i nie pomyliłem się. Mimo wszystko zostałem wyróżniony i dostałem gadżety firmowe. Niestety ucho od kubka się potłukło w transporcie, ale jakoś mi specjalnie na nim nie zależało. Liczy się satysfakcja, z rozwiązanych zadań.

Podsumowując, obydwie wysokie oceny z warsztatów motywują mnie do dalszego działania w sferze dzielenia się moją wiedzą z innymi. Jeśli więc chciałbyś, abym poprowadził któryś w/w warsztatów u Ciebie w mieście / w firmie, daj znać na priv – e-mail do mnie znajdziesz na tej stronie.

A jeśli nie miałeś/-aś okazji uczestniczenia w moich warsztatach podczas Warsjawy, to być może, niedługo będzie taka możliwość w okolicach Wrocławia. Po więcej szczegółów zapraszam na stronę: chamberconf.pl

Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty

W tym roku miałem okazję poprowadzić 2 warsztaty na Warsjawie. Wcześniej prowadziłem jedynie prezentacje (czy to w pracy czy na WrocławJUG), a w formie warsztatów to był mój pierwszy raz! I od razu 2 różne tematy!

Jak mi poszło? Uważam, że co najmniej dobrze. Wydaje mi się, że nie miałem większych potknięć, feedback zbierany od uczestników jest jak dotychczas pozytywny.

Podobne opinie słyszałem, gdy się podpytywałem uczestników, jak i przeczytałem w e-mailach. Pewnie coś więcej będę mógł się dowiedzieć (zwłaszcza liczę na uwagi krytyczne, aby wiedzieć co poprawić następnym razem), gdy uczestnicy wypełnią ankietę pokonferencyjną. Wszelakie e-maile i komentarze również mile widziane.

A tymczasem zamieszczam poniżej materiały z których korzystałem.

Upiększ swoje testy! Testowanie jednostkowe dla średniozaawansowanych.

Kod używany na warsztacie: https://github.com/mstachniuk/SolarSystem

Poznaj lepiej swoje srodowisko programistyczne i zwieksz swoja produktywnosc z IntelliJ Idea.

Kod napisany przez uczestników podczas warsztatów: https://github.com/mstachniuk/WarsjawaCodingDojo

Co do samej konferencji, to minusy (z punktu widzenia prelegenta):
- nie do końca przygotowane sale (rzutnik, nasłonecznienie, jakieś pudła)
- system do komunikacji z uczestnikami nie wysyła załączników i wiadomości nie dochodzą do wszystkich
- nie do końca udany pomysł ze szwendaniem się po knajpach po konferencji

A na plus:
- obecność zagranicznych spikerów
- wcześniejsza rejestracja dla prelegentów
- transparentnosć, co ile kosztowało
- długie przerwy, dobry timeline

I oby tak dalej, albo i jeszcze lepiej!

Implementacja Singleton’a w Javie

Ostatnio, podczas z jednej z rozmów rekrutacyjnych, dostałem pytanie, "A jak by Pan zaimplementował singleton w Javie?". Pytanie dość standardowe, mógł by je zadać każdy. Odpowiadam więc: „Klasa, z prywatnym konstruktorem, z polem statycznym o typie zadeklarowanej klasy, metoda getInstnce(), itd.”. Rekruter na to: "No dobra, a jakiś inny pomysł?".

Na szybko nie przychodziło mi jednak nic do głowy... Wtedy padło pytanie, które zmotywowało mnie do przygotowania tego wpisu: "A czytał Pan Effective Java, Joshua Bloch?". A no nie czytałem i nie sądzę, abym ją przeczytał.

Dlaczego?

Przede wszystkim uważam że ta książka jest trochę przestarzałą. Drugie wydanie pochodzi z 2008 roku i informacje w niej zawarte są trochę nieaktualne. To nie książka o wzorcach projektowych Bandy Czworga, która nie traci na swojej aktualności, a jedynie pozycja o tym jak coś tam dobrze zrobić w Javie. I tak przykładowo rozdział: "Item 51 Beware the performance of string concatenation", traktujące o tym, aby lepiej używać StringBuilder’a niż + do sklejania tekstów, jest już dawno nieaktualne! Chciałem kiedyś pisać posta o tym, ale na stackoverflow i jeszcze gdzieś tam już dawno o tym było. Nie wiem tylko od kiedy dokładnie istnieje ten mechanizm zamiany + na StringBuilder’a w Javie.

O innych dobrych praktykach, można się dowiedzieć zawsze z innych źródeł, niekoniecznie czytając wspomnianą książkę.

Dobra wróćmy do tematu wpisu. W innym rozdziale Effective Java (Item 3: Enforce the singleton property with a private constructor or an enum type), jest zalecenie, aby Singletona implementować za pomocą Enuma. Z tym rozwiązaniem spotkałem się po raz pierwszy podczas review kodu kogoś, kto czytał tę książkę. Użycie wówczas enuma w roli singletonu było dla mnie zupełnie niezrozumiałe! Musiałem dopytać autora o co chodzi.

Dlaczego nie lubię tego rozwiązania? Spójrzmy na przykładowy kawałek kodu (inspirowany Joshuą Blochem, co bym za dużo nie musiał wymyślać, jak tu mądrze użyć singletona). Kod jest i tak kiepski (obliczanie czasu), ale chodzi mi o zaprezentowanie działania omawianego wzorca.

public enum Elvis {
    INSTANCE;

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

public class ElvisProfitService {

    public double ELVIS_SALARY_YEAR = 70_000;

    public double calculateElvisProfit() {
        return Elvis.INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }
}

No i weź tu panie przetestuj taki kod! Możemy jeszcze Elvisa statycznie zaimportować, to linijka 6 skróci się do jeszcze mniej czytelnej formy.

return INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;

Ktoś ma jakieś pomysły jak taki kod przetestować? Da się oczywiście, z wykorzystaniem PowerMock’a [link do rozwiązania na końcu ^1], ale chyba nie o to chodzi aby pisać nietestowany kod?

Dlaczego wolę starszą wersję tegoż rozwiązania:

public class Elvis {

    private static final Elvis INSTANCE = new Elvis();

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    private Elvis() {
    }

    public static Elvis getInstance() {
        return INSTANCE;
    }

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

Dochodzi prywatny konstruktor, statyczna metoda getInstance() i inicjalizacja pola klasy wraz z deklaracją.

W tym przypadku kod korzystający z tego singletonu, mógłby być następujący:

public class ElvisProfitService {

    private final double ELVIS_SALARY_YEAR = 70_000;
    private Elvis elvis = Elvis.getInstance();

    public double calculateElvisProfit() {
        return elvis.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }

    // For tests
    void setElvis(Elvis elvis) {
        this.elvis = elvis;
    }
}

W linii 4 wywołałem getInstance(), aby w przykładowym kodzie produkcyjnym było wszystko cacy. Dzięki temu, zależność ta jest definiowana jako pole w kasie i mamy setter do tego, więc możemy sobie bardzo ładnie przetestować tą funkcjonalność, bez hackowania z PowerMockiem:

public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();
        Elvis elvis = mock(Elvis.class);
        when(elvis.howOldIsElvisNow()).thenReturn(1);
        service.setElvis(elvis);

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

W sekcji given mamy bardzo ładnie zdefiniowane zachowanie, za pomocą Mockito, jakie ma przyjmować masz singleton na potrzeby tego testu.

A Ty jak definiujesz (o ile to robisz) swoje singletony? Które rozwiązanie uważasz za lepsze?

---

[1] Co do rozwiązania zagadki, jak przetestować Singletona jako Enum’a, to tutaj jest odpowiednia rewizja na github’ie: SingletonInJava e714fb a kod poniżej:

@RunWith(PowerMockRunner.class)
@MockPolicy(ElvisMockPolicy.class)
public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

public class ElvisMockPolicy implements PowerMockPolicy {

    @Override
    public void applyClassLoadingPolicy(MockPolicyClassLoadingSettings settings) {
        settings.addFullyQualifiedNamesOfClassesToLoadByMockClassloader("com.blogspot.mstachniuk.singletoninjava.Elvis");
    }

    @Override
    public void applyInterceptionPolicy(MockPolicyInterceptionSettings settings) {
        Method method = Whitebox.getMethod(Elvis.class, "howOldIsElvisNow");
        settings.proxyMethod(method, new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                return 1.0;
            }
        });
    }
}

I znów Global Day Of Code Retreat

Kolejny rok mija i kolejny Global Day of Code Retreat już za nami. W tym roku planowałem początkowo uczestniczyć w tym evencie w Wolfsburgu, ale ostatecznie wybrałem Berlin, aby się trochę zorientować, jak wygląda tamtejsza sytuacja projektowa i mieszkaniowa. A CR to zawsze dobra okazja do tego. To już kolejny raz (6ty, jeśli nie licząc jakiś mniejszych, wewnętrznych inicjatyw), kiedy biorę udział w tego typie wydarzeniu, więc widzę jak się ono zmienia w czasie. Rok temu prawie 200 miast na całym świecie organizowało CR, a w tym było 165 lokalizacji. Tendencja więc spadkowa.

Jako że Berlin uchodzi za bardzo Europejskie miasto(o czym wspominałem już kiedyś w poprzedniej relacji), spotkanie było prowadzone po angielsku. Jednak w międzyczasie można było usłyszeć sporo języka niemieckiego, jaki i polskiego:) Zaczęliśmy więc od sortowania uczestników bąbelkowo, aby zorientować się kto jest mocny w TDD, pair programingu, a kto jest kompletnie świeży. No i w ten sposób najlepsi zasiedli do wspólnego stanowiska pracy z kompletnymi świeżakami. Nie ma to jak nauczanie innych:)

W pierwszej sesji dostałem więc niemieckiego studenta, który w javie pisze od święta, studiuje coś tam powiązane z medycyną, a na co dzień klepie w php. Używa do tego Vim’a. Jest on do niego tak przyzwyczajony, że korzysta z ichniejszych skrótów klawiszowych bezpośrednio w Eclipsie. Byłem pod wrażeniem, choć wątpię, aby była to optymalna droga do wykorzystania w pełni możliwości Eclipse’a.

Drugą sesję pokodowałem z przyjacielem Szymonem, z którym wspólnie przyjechałem do Berlina. Pobawiliśmy się trochę Scalą, ale nie szło nam jakoś najlepiej. Na pewno jeszcze sporo czasu trzeba zainwestować w poznawanie tego języka, aby móc z niego swobodnie korzystać. Niestety kiepska pogoda w ostatnim czasie, brak śniegu i gorączka przedświąteczna, nie jest najlepszym czasem do nauki nowych rzeczy. Dlatego kurs na Courserze sobie troszkę odpuściłem:(

Trzecią sesję miałem sposobność spędzić z pewnym Syryjczykiem, który na co dzień jest adminem, ale chciałby robić jakieś przyjemniejsze rzeczy. Ta sesja była dla mnie bardzo wymagająca pod względem komunikacji, ze względu na mój nienajlepszy angielski, ciężki w zrozumieniu angielski partnera i jego trochę słabą wiedzę w zakresie Javy. Myślę, że ziomek się sporo ode mnie nauczył.

Po trzeciej sesji była mała retrospekcja. W grupach 3 osobowych, mieliśmy napisać na kartkach, co się nauczyliśmy i co chcielibyśmy się nauczyć. Kartki przykleiliśmy na szybę i chwilę o tym dyskutowaliśmy.

Później była przerwa obiadowa. Były kanapki, a nie porządny ciepły, pyszny obiad jak to jest w formule tego wydarzenia zapisane. No ale trudno, nie to jest przecież najważniejsze.

Na 4tej sesji znów próbowałem pisać w Scali z innym nowopoznanym kolegą z Wrocławia. Tutaj trochę ciężko było nam dojść do porozumienia, gdyż zmierzaliśmy w innych kierunkach: ja kładłem nacisk na TDD, a kolega na implementację i lukier składniowy, jak to można by lepiej i ładnie zrobić w Scali.

Po czwartej sesji musieliśmy jednak opuścić warsztaty. Podziękowania dla globalnych i kontynentalnych sponsorów wydarzenia, a także dla sponsora w Berlinie: ImmobilienScout24, gdzie odbywał się event. Podziękowania również dla Martina Klose (@martinklose), który jak zwykle stanął na wysokości zadania i dobrze poprowadził kolejny raz to wydarzenie.

A co się zmienia, jeśli chodzi o Code Retreat? W Berlińskiej edycji zastosowano fajny pomysł przy rejestracji. Należało zapłacić 15 Euro, które było później zwracane, gdy uczestnik się pojawił na spotkaniu. Motywowało to ludzi do przychodzenia, gdy już byli zapisani, a gdyby naprawdę coś komuś nagłego wypadło, to strata 15 E jest do przełknięcia. Uważam to za super pomysł.

Ponadto zauważyłem, że osoby bardziej doświadczone w TDD i w formule Code Retreat już nie tak licznie w nim uczestniczą. Może to wynika z braku chęci nauczania innych, lub są już zmęczenie problemem gry w życie? Albo stwierdzają, że już nic nowego nie mogą się nauczyć i wybierają inne, ciekawsze aktywności w tym czasie. Ciężko mi to oceniać, ale wydaje mi się, jakby młodsi niedoświadczeni uczestnicy byli bardziej widoczni na tego typu wydarzeniach. To oznacza, że nadchodzą nowi, pełni zapału i żądzy wiedzy programiści, a więc tym bardziej nie można zostawać z tyłu…

Porównanie tradycyjnych asercji, Hamcrest'a i FEST'a

Po tygodniowym szaleństwie w Alpach i niewielkim odmrożeniu, czas wrócić do pracy aby odpocząć ;) Temat może nie będzie zbytnio odkrywczy, ale akurat prezentowałem kolegom w projekcie jak działa FEST Asserts 2.X, więc niewielkim nakładem pracy można coś na blogu o tym skrobnąć. Jak ktoś już zna i używa, to nie musi dalej czytać. A kto nie zna jeszcze FEST’a to niech się przyjrzy przykładom przygotowanym przeze mnie i upiększy swoje nowe testy.

O wyższości FEST’a nad Hamcrest'em słyszałem po raz pierwszy na prezentacji Bartosza Bańkowskiego i Szczepana Fabera pt. Pokochaj swoje testy na Wroc JUG. I to już było wiadome w 2009 roku. W międzyczasie Hamcrest został wciągnięty do JUnit'a i Mockito, ale to z innych względów. A tym czasem FEST Asserts został trochę odświeżony i podbito jego numerek wersji. Dalej jest bardzo dobry i pozwala lepiej definiować fachowe asercje.

Czas na przykład. Jest on całkiem życiowy, aczkolwiek domena problemu została zmieniona i trochę uproszczona dla przejrzystości przykładu. Ja po zobaczeniu podobnego kodu u siebie w projekcie, podczas review, gdzie pewien proces zwracał sporo skomplikowanych wyników, stwierdziłem, że muszę natychmiast zastosować FEST’a. Trochę nawijki z architektem i dostałem zielone światło. Test w pierwszej, typowej JUnit’owej formie poniżej:

@Test
public void shouldGenerateInnerPlanets() {
 // given
 SolarSystem solarSystem = new SolarSystem();

 // when
 Set<Planet> innerPlanets = solarSystem.getInnerPlanets();

 // then
 assertEquals(4, innerPlanets.size());
 for (Planet innerPlanet : innerPlanets) {
  if (innerPlanet.getName().equals("Mercury")) {
   List<Gases> mercuryGases = asList(Gases.OXYGEN, Gases.SODIUM, Gases.HYDROGEN);
   assertPlanet(innerPlanet, RotationDirection.LEFT, 4_879_400, 87.96935, 3.701, mercuryGases);
  } else if (innerPlanet.getName().equals("Venus")) {
   List<Gases> venusGases = asList(Gases.CARBON_DIOXIDE, Gases.NITROGEN);
   assertPlanet(innerPlanet, RotationDirection.RIGHT, 12_103_700, 224.700_96, 8.87, venusGases);
  } else if (innerPlanet.getName().equals("Earth")) {
   List<Gases> earthGases = asList(Gases.NITROGEN, Gases.OXYGEN);
   assertPlanet(innerPlanet, RotationDirection.LEFT, 12_756_273, 365.256_363_004, 9.806_65, earthGases);
  } else if (innerPlanet.getName().equals("Mars")) {
   List<Gases> marsGases = asList(Gases.CARBON_DIOXIDE, Gases.NITROGEN);
   assertPlanet(innerPlanet, RotationDirection.LEFT, 6_804_900, 686.960_1, 3.69, marsGases);
  } else {
   throw new AssertionError("Undefined Planet Name: " + innerPlanet.getName()
     + " in result\n" + innerPlanet.toString());
  }
 }
}

private void assertPlanet(Planet planet, RotationDirection direction, long diameterInMeter,
        double yearInEarthDays, double acceleration, List<Gases> atmosphereGases) {
 assertEquals(direction, planet.getRotationDirection());
 assertEquals(diameterInMeter, planet.getDiameter());
 assertEquals(yearInEarthDays, planet.getSiderealYear().inEarthDays(), 0.01);
 assertEquals(acceleration, planet.getAcceleration(), 0.01);
 for (Gases gas : atmosphereGases) {
  assertTrue("Planet " + planet.getName() + " doesn't contains " + gas,
    planet.getAtmosphereGases().contains(gas));
 }
}  

Testujemy metodę generującą zbiór planet wewnętrznych, czyli 4ch pierwszych z naszego układu słonecznego. Pierwsza asercja w linii 10 sprawdza, czy metoda zwróciła odpowiednią ilość planet. Co się stanie, gdy w wyniku będzie nieprawidłowa ilość elementów? Będziemy o tym wiedzieć, ale co dokładnie jest, a czego nie ma, nie będzie wyszczególnione w komunikacie błędów zepsutego testu. Można do pracy wtedy za prząść debugera, ale ja jego nienawidzę.

Kolejny problem to konieczność odszukania właściwego obiektu. Nasza testowana metoda zwraca zbiór planet, przez co nie możemy być pewni, co do kolejności obiektów w wyniku. Dzięki temu dostaliśmy brzydki blok if-else. W takim każdym if’ie definiowana jest najpierw lista gazów, jakie ma zawierać dana planeta. Można by było to co prawda zrobić inline w wywołaniu assertPlanet(), ale wtedy w ogóle łańcuszek argumentów byłby nieczytelny.

Drugim elementem każdego if’a jest właśnie wywołanie assertPlanet() z jakimiś argumentami. Co one oznaczają? Trzeba skoczyć do ciała metody i sprawdzić. Jaka jest ich kolejność? Przy takiej ich liczbie na pewno jej nie zapamiętamy na dłużej niż 5 minut. Można ewentualnie zrezygnować z metody assertPlanet() i ją zinline’nować, ale wtedy mamy sporo duplikacji w kodzie, niskiej czytelności i słabej reużywalności.

Czas na wersję tego samego kodu z Hamcrestem.

@Test
public void shouldGenerateInnerPlanets() {
 // given
 SolarSystem solarSystem = new SolarSystem();

 // when
 Set<Planet> innerPlanets = solarSystem.getInnerPlanets();

 // then
 assertThat(innerPlanets, hasItem(withName("Mercury")));
 Planet mercury = findPlanetByName(innerPlanets, "Mercury");
 assertThat(mercury, is(rotation(RotationDirection.LEFT)));
 assertThat(mercury, is(diameterInMeter(4_879_400)));
 assertThat(mercury, is(yearLongInEarthDays(87.96935)));
 assertThat(mercury, is(acceleration(3.701)));
 assertThat(mercury, hasGas(Gases.OXYGEN));
 assertThat(mercury, hasGas(Gases.SODIUM));
 assertThat(mercury, hasGas(Gases.HYDROGEN));

 assertThat(innerPlanets, hasItem(withName("Venus")));
 Planet venus = findPlanetByName(innerPlanets, "Venus");
 assertThat(venus, is(rotation(RotationDirection.RIGHT)));
 assertThat(venus, is(diameterInMeter(12_103_700)));
 assertThat(venus, is(yearLongInEarthDays(224.700_96)));
 assertThat(venus, is(acceleration(8.87)));
 assertThat(venus, hasOnlyGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN));

 assertThat(innerPlanets, hasItem(withName("Earth")));
 Planet earth = findPlanetByName(innerPlanets, "Earth");
 assertThat(earth, is(rotation(RotationDirection.LEFT)));
 assertThat(earth, is(diameterInMeter(12_756_273)));
 assertThat(earth, is(yearLongInEarthDays(365.256_363_004)));
 assertThat(earth, is(acceleration(9.806_65)));
 assertThat(earth, hasGases(Gases.NITROGEN, Gases.OXYGEN));
 assertThat(earth, hasNotGases(Gases.SODIUM));

 assertThat(innerPlanets, hasItem(withName("Mars")));
 Planet mars = findPlanetByName(innerPlanets, "Mars");
 assertThat(mars, is(rotation(RotationDirection.LEFT)));
 assertThat(mars, is(diameterInMeter(6_804_900)));
 assertThat(mars, is(yearLongInEarthDays(686.960_1)));
 assertThat(mars, is(acceleration(3.69)));
 assertThat(mars, hasGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN));
 assertThat(mars, hasNotGases(Gases.OXYGEN));

 assertThat(innerPlanets, hasSize(4));
}

Kod wygląd już bardziej czytelnie, ale musiałem do tego dopisać 8 klas Matcher’ów. Właściwie na każdą asercję potrzeba oddzielnego Matcher’a. Mimo wszystko nie pozbyliśmy się problemu wyszukiwania potrzebnego obiektu, co widać w linii 11. Może jest jakieś lepsze obejście na to, ale ja nie znalazłem. Na koniec testu, warto jeszcze sprawdzić, czy testowany zbiór posiada żądaną ilość elementów. Jednak tutaj i tak ewentualny komunikat błędu będzie mało czytelny.

Dobra czas na gwiazdę wieczoru, czyli na test napisany z wykorzystaniem FEST’a.

@Test
public void shouldGenerateInnerPlanets() {
 // given
 SolarSystem service = new SolarSystem();

 // when
 Set<Planet> innerPlanets = service.getInnerPlanets();

 // then
 assertThat(innerPlanets)
   .containsPlanetWithName3("Mercury")
   .withRotation(RotationDirection.LEFT)
   .withDiameterInMeter(4_879_400)
   .withYearInEarthDays(87.96935)
   .withAcceleration(3.701)
   .withGas(Gases.OXYGEN)
   .withGas(Gases.SODIUM)
   .withGas(Gases.HYDROGEN);

 assertThat(innerPlanets)
   .containsPlanetWithName3("Venus")
   .withRotation(RotationDirection.RIGHT)
   .withDiameterInMeter(12_103_700)
   .withYearInEarthDays(224.700_96)
   .withAcceleration(8.87)
   .containsOnlyGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN);

 assertThat(innerPlanets)
   .containsPlanetWithName3("Earth")
   .withRotation(RotationDirection.LEFT)
   .withDiameterInMeter(12_756_273)
   .withYearInEarthDays(365.256_363_004)
   .withAcceleration(9.806_65)
   .containsGases(Gases.NITROGEN, Gases.OXYGEN)
   .doesNotContainGases(Gases.SODIUM);

 assertThat(innerPlanets)
   .containsPlanetWithName3("Mars")
   .withRotation(RotationDirection.LEFT)
   .withDiameterInMeter(6_804_900)
   .withYearInEarthDays(686.960_1)
   .withAcceleration(3.69)
   .containsGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN)
   .doesNotContainGases(Gases.OXYGEN);

 assertThat(innerPlanets)
   .containsOnlyPlanets("Mercury", "Venus", "Earth", "Mars");
} 

Początek testu jest taki jak w poprzednich przypadkach, ale od sekcji  //then  robi się ciekawie. Widać wyraźnie 4 logicznie oddzielone od siebie bloki, po jednym na sprawdzenie każdej z planet. Można też łatwo zauważyć łańcuch wywołań, który powinien nam być przynajmniej ze wzorca Bulder znany, a który można ogólniej zdefiniować, jako fluent interface. Hamcrest stara się również iść w tym kierunku, ale jak dla mnie te zapis jest bardziej zwięzły i przejrzysty. Mamy po prostu nazwę właściwości, którą weryfikujemy, konkretną wartość i zazwyczaj jakiś prefix w nazwie metody. Ja preferuję dla kolekcji prefix contains, a dla konkretnych właściwości with lub has. Ale jest to już kwestia umowna, co komu lepiej leży.

Jak więc tworzyć takie asercje?

public class PlanetSetAssert extends AbstractAssert<PlanetSetAssert, Set<Planet>> {

    private PlanetSetAssert(Set<Planet> actual) {
        super(actual, PlanetSetAssert.class);
    }

    public static PlanetSetAssert assertThat(Set<Planet> actual) {
        Assertions.assertThat(actual)
                .isNotNull();
        return new PlanetSetAssert(actual);
    }

    public PlanetSetAssert containsPlanetWithName(String expectedPlanetName) {
        for (Planet planet : actual) {
            if(planet.getName().equals(expectedPlanetName)) {
                return this;
            }
        }
        throw new AssertionError("Actual Set doesn't contains Planet with name: " + expectedPlanetName);
    } 

Aby stworzyć własną, fachową asercję, należy rozszerzyć klasę AbstractAssert. Ta przyjmuje za dwa typy generyczne kolejno samą siebie i typ który będziemy obsługiwać, w tym przypadku Set<Planet>. Później definiujemy konstruktor, który jako argument bierze badany obiekt. Konstruktora nie będziemy wywoływać poza obrębem tej klasy, więc można go uczynić prywatnym. Korzystać natomiast będziemy ze statycznej metody fabrykującej assertThat(), która to jako jedyna ze zdefiniowanego wcześniej konstruktora korzysta. Ja preferuję w tym miejscu od razu sprawdzić, czy przekazany obiekt nie jest null’em. Oficjalny tutoral (swoją drogą bardzo dobry, z licznymi komentarzami) preferuje wykonywać to sprawdzenie w każdej metodzie, ale jak dla mnie to jest niepotrzebna redundancja.

Na koniec jest przykładowa implementacja metody, sprawdzającej, czy w danym zbiorze znajduje się planeta o podanej nazwie. W tym przypadku metoda zwraca this, co pozwala wywoływać łańcuchowo dalsze asercje na zbiorze planet. Minusem takiego podejścia jest konieczność definiowania własnego komunikatu błędu, w przypadku niepowodzenia – linia 19. W przypadku gdy zależy nam na sprawdzeniu, czy dany zbiór zawiera szukany element, można tą samą funkcjonalność zaimplementować troszkę inaczej.

public PlanetSetAssert containsPlanetWithName2(String expectedPlanetName) {
 Planet expectedPlanet = new Planet(expectedPlanetName);

 Assertions.assertThat(actual)
   .usingElementComparator(new PlanetNameComparator())
   .contains(expectedPlanet);
 return this;
}

private class PlanetNameComparator implements Comparator<Planet> {
 @Override
 public int compare(Planet p1, Planet p2) {
  return p1.getName().compareTo(p2.getName());
 }
} 

W tym przypadku, za pomocą metody usingElementComparator(), podmieniamy sposób porównywania elementów w kolekcji. Bardzo użyteczny mechanizm. Nadpisujemy tylko typowego porównywacza (komparatora) i gotowe. I co fajniejsze, to dostajemy bardzo przejrzysty komunikat błędu:

java.lang.AssertionError: expecting:
<[Venus, Earth, Mars]>
 to contain:
<[Mercury]>
 but could not find:
<[Mercury]>
 according to 'PlanetNameComparator' comparator
 at com.blogspot.mstachniuk.hamcrestvsfest.fest.PlanetSetAssert.containsPlanetWithName2(PlanetSetAssert.java:34)
  at com.blogspot.mstachniuk.hamcrestvsfest.fest.SolarSystemFestTest.shouldGenerateInnerPlanets(SolarSystemFestTest.java:24)

Właśnie przejrzyste komunikaty błędów (zwłaszcza wśród kolekcji) to siła tego narzędzia.

Teraz czas na moją ulubioną implementację tego typu metody, która to pozwala nam budować jeszcze bardziej płynące interfejsy:

public PlanetAssert containsPlanetWithName3(String expectedPlanetName) {
 Planet expectedPlanet = new Planet(expectedPlanetName);

 PlanetNameComparator comparator = new PlanetNameComparator();
 Assertions.assertThat(actual)
   .usingElementComparator(comparator)
   .contains(expectedPlanet);

 for (Planet planet : actual) {
  if(comparator.compare(planet, expectedPlanet) == 0) {
   return PlanetAssert.assertThat(planet);
  }
 }
 return null;
} 

Początek metody jest analogiczny jak w poprzednim przykładzie. Natomiast zamiast zwracać obiekt this, wyszukuję żądany element i zwracam już asercję, dla tej znalezionej planety. Dzięki temu mogę już sprawdzić inne jej właściwości. Właściwie, mógłbym w pętli wywołać zwykłą metodę equals() do wyszukania elementu, ale skoro mam już napisanego komparatora…

Wrcając jeszcze to całego kodu z listingu 3, to warto na końcu metody testowej jeszcze sprawdzić, czy w zwracanym wyniku, są tylko te planety, których się spodziewamy (jeśli tak mamy w wymaganiach). Przykładowa implementacja, jak to można zrobić:

public PlanetSetAssert containsOnlyPlanets(String... planets) {
 List<Planet> expectedPlanets = new ArrayList<Planet>();
 for (String planet : planets) {
  Planet p = new Planet(planet);
  expectedPlanets.add(p);
 }
 Assertions.assertThat(actual)
   .usingElementComparator(new PlanetNameComparator())
   .containsOnly(expectedPlanets.toArray(new Planet[expectedPlanets.size()]));
 return this;
}

Co ogólnie jest jeszcze fajnego w takich asercjach? To to, że sprawdzamy dokładnie to co chcemy sprawdzić, zamiast sprawdzać zawsze wszystko, jak było to w pierwszej wersji testu. Również zdefiniowałem sobie różne metody odnośnie sprawdzania występujących na danej planecie gazów atmosferycznych: withGas(Gases.OXYGEN), containsGases(Gases.NITROGEN, Gases.OXYGEN), containsOnlyGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN), doesNotContainGases(Gases.SODIUM). Do wyboru do koloru / potrzeby. Po więcej szczegółów odsyłam do wiki projektu.

Z ciekawostek, warto jeszcze zaprezentować generator FEST asercji. Można sobie to samemu przetestować, ściągając mój projekt z github’a i odpalając assertion-generator\planet.bat. Skrypt automatycznie kopiuje wygenerowaną klasę do podkatalogu fest2 gdzieś w hierarchii testowej, gdzie jednocześnie znajduje się test niej korzystający. Wystarczy zmienić nazwę pakietu i doimportować potrzebne klasy, aby test z powrotem działał.

Tak wygląda kod, który korzysta z przykładowo wygenerowanych asercji:

@Test
public void shouldGenerateInnerPlanets() {
 // given
 SolarSystem service = new SolarSystem();

 // when
 Set<Planet> innerPlanets = service.getInnerPlanets();

 // then
 Planet mercury = findPlanetByName(innerPlanets, "Mercury");
 assertThat(mercury)
   .hasRotationDirection(RotationDirection.LEFT)
   .hasDiameter(4_879_400)
   .hasSiderealYear(new SiderealYear(87.96935))
   .hasAcceleration(3.701)
   .hasAtmosphereGases(Gases.OXYGEN, Gases.SODIUM, Gases.HYDROGEN);

 Planet venus = findPlanetByName(innerPlanets, "Venus");
 assertThat(venus)
   .hasRotationDirection(RotationDirection.RIGHT)
   .hasDiameter(12_103_700)
   .hasSiderealYear(new SiderealYear(224.700_96))
   .hasAcceleration(8.87)
   .hasAtmosphereGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN);

 Planet earth = findPlanetByName(innerPlanets, "Earth");
 assertThat(earth)
   .hasRotationDirection(RotationDirection.LEFT)
   .hasDiameter(12_756_273)
   .hasSiderealYear(new SiderealYear(365.256_363_004))
   .hasAcceleration(9.806_65)
   .hasAtmosphereGases(Gases.NITROGEN, Gases.OXYGEN);

 Planet mars = findPlanetByName(innerPlanets, "Mars");
 assertThat(mars)
   .hasRotationDirection(RotationDirection.LEFT)
   .hasDiameter(6_804_900)
   .hasSiderealYear(new SiderealYear(686.960_1))
   .hasAcceleration(3.69)
   .hasAtmosphereGases(Gases.CARBON_DIOXIDE, Gases.NITROGEN);
}

Niestety musimy sami sobie dopisać metodę szukającą odpowiednią planetę, albo asercję dla Set<Planet>. W wygenerowanym kodzie jest jednoznaczna konwencja, że wszystkie metody sprawdzające nasze własności, dostają prefix has. Można sobie oczywiście to i sporo innych rzeczy zmienić w szablonach generowanego kodu.

A jak komuś mało takie generowanie kodu, to może sobie ten kod generować podczas builda maven’owego, dzięki Maven plugin for fest-assertion-generator. Można to również w moim przykładowym projekcie przetestować, usuwając pliki *Assert.java z katalogu: com\blogspot\mstachniuk\hamcrestvsfest\. Wówczas po odpaleniu mvn install, lub mvn test lub mvn generate-test-sources zostaną wygenerowane na nowo pliki z asercjami. Wówczas test SolarSystemFest3Test, który z nich korzysta, będzie nadal działał.

Ostatnio pojawił się jeszcze plugin do Eclipse’a: FEST eclipse plugin generujący prosto z tegoż środowiska nasze asercje. Zapowiada się ciekawie, więc zachęcam do skorzystania.

Pomyślnych asercji!

Logowanie interakcji w Mockito

Ostatnio przyszedł do mnie mój architekt i zaczął rozmowę coś w stylu:

Marcin, ty nasz ekspercie od testowania jednostkowego, integracyjnego i Mockito…

Ucieszony miłymi słowami pochwały i podbudowany faktem, że stanowię ważną część zespołu słuchałem dalej, co ma mi do powiedzenia kolega z zespołu. Wtedy jeszcze nie wiedziałem, że to pierwsze zdanie to tak naprawdę prosta, skuteczna, magiczna sztuczka, dzięki której bardzo łatwo jest później przekonać odbiorcę tego komunikatu, do wykonania pewnego zdania. To już trochę zahacza o manipulację / wywoływanie (ang. elicitation) / urabianie / programowanie neurolingwistyczne, czy też inne tego typu techniki, a więc wykracza po za tematykę tego bloga.

Wracając do rozmowy:

No bo właśnie mamy taki problem, że zrobiliśmy refaktoring niedawno stworzonej klasy i generalnie wszystko działa, ale trzeba jeszcze testy dopasować. Ten i tamten już poszli do domu, więc pytam czy byś tego nie zrobił. Uważam, że Tobie, jako że jesteś najbardziej w testach zorientowany, pójdzie szybko i gładko...

No dobra, myślę sobie. Dzisiaj kończy się czas przeznaczony na kodowanie w tym Sprincie, trzeba więc cos zdeployować, aby testerzy mieli jutro co robić. No dobra, obowiązki wzywają.

Architekt pokazał mi i opisał jakie to zmiany zostały wykonane. Generalnie był to pewien proces, który kodowaliśmy przez cały sprint. Miał on wiele danych wejściowych i generował sporo na wyjściu. No i wcześniej była sobie taka jedna metoda, która to miała 6 argumentów, kilka mocków i produkowała coś pożytecznego. Zostało to opakowane w fabrykę, która podawała teraz cześć danych od dupy strony (wywołanie innych serwisów), jak i również sama metoda została przeorana. Czyli liczba argumentów zmalała, doszło kilka zależności, nowy sposób instancjowania, no i trzeba był do tego przerobić testy.

Cofnięcie zmian nie wchodziło w rachubę, gdyż była to sprawka w sumie 3ch osób, a wykorzystywany system kontroli wersji (dziękujemy IBM Synergy) zrobił by więcej złego niż dobrego. Olanie testów jedynie przesuwało problem w czasie, a na syndrom wybitego okna nie mogłem sobie pozwolić.

Zacząłem więc to po kolei przerabiać testy, ich czytelność malała, a definicje zachowania mocków stawały się niezrozumiałe. Najgorsze że pierwszy test, który przerabiałem, ciągle nie działał. Nie wiedziałem w końcu czy to wina domyślnych wartości zwracanych przez Mocki z Mockito, czy też trefnego refactoringu (a raczej redesignu).

No i w tym momencie postanowiłem sprawdzić interakcje z moimi mockami, czy czasem gdzieś przypadkiem Mockito nie zwraca np. pustej listy, która to powoduje brak wyników. Chwila szperania w dokumentacji i znalazłem taki ciekawy twór. Przykładowy kod poniżej.

@Test
public void shouldCreateAccount() {
    // given
    InvocationListener logger = new VerboseMockInvocationLogger();
    AccountService accountService = new AccountService();
    StrengthPasswordValidator validator = mock(
            StrengthPasswordValidator.class,
            withSettings().invocationListeners(logger));
    UserDao userDao = mock(UserDao.class,
            withSettings().invocationListeners(logger));
    UserFactory userFactory = mock(UserFactory.class,
            withSettings().invocationListeners(logger));

    when(userFactory.createUser(LOGIN, PASSWORD))
            .thenReturn(new User(LOGIN, PASSWORD));

    accountService.setPasswordValidator(validator);
    accountService.setUserDao(userDao);
    accountService.setUserFactory(userFactory);

    // when
    User user = accountService.createAccount(LOGIN, PASSWORD);

    // then
    assertEquals(LOGIN, user.getLogin());
    assertEquals(PASSWORD, user.getPassword());
} 

Testujemy zakładanie konta użytkownika. Życiowy przykład, wiele nie trzeba tłumaczyć.

Na początek w linii 4tej tworzymy instancję obiektu typu VerboseMockInvocationLogger. Jest to standardowa implementacja interfejsu InvocationListener, która wypisuje na standardowe wyjście zaistniałe interakcje z mockami. Aby przekazać ten obiekt do naszych mocków, musimy podczas ich tworzenia, ustawić ten obiekt. Jak? Widzimy to w linii 8smej. Powtarzamy to dla każdego mocka, który nas interesuje.

Dalej standardowo. Za pomocą when() konfigurujemy Mock’a, injectujemy zaleznosci (linie 17-19) wywołanie metody testowej i assercje. Dzięki takiemu Testu możemy otrzymać interesujący output:

########### Logging method invocation #1 on mock/spy ########
userFactory.createUser("login", "password");
   invoked: -> at com.blogspot.mstachniuk.unittestpatterns.service.mockinvocations.AccountServiceTest.shouldCreateAccount(AccountServiceTest.java:31)
   has returned: "null"

############ Logging method invocation #2 on mock/spy ########
strengthPasswordValidator.validate(
    "password"
);
   invoked: -> at com.blogspot.mstachniuk.unittestpatterns.service.AccountService.createAccount(AccountService.java:19)
   has returned: "0" (java.lang.Integer)

############ Logging method invocation #3 on mock/spy ########
userDao.findUserByLogin("login");
   invoked: -> at com.blogspot.mstachniuk.unittestpatterns.service.AccountService.existAccount(AccountService.java:43)
   has returned: "null"

############ Logging method invocation #4 on mock/spy ########
   stubbed: -> at com.blogspot.mstachniuk.unittestpatterns.service.mockinvocations.AccountServiceTest.shouldCreateAccount(AccountServiceTest.java:31)
userFactory.createUser("login", "password"); 
   invoked: -> at com.blogspot.mstachniuk.unittestpatterns.service.AccountService.createAccount(AccountService.java:23)
   has returned: "User{login='login', password='password'}" (com.blogspot.mstachniuk.unittestpatterns.domain.User)

Pierwsze wywołanie, to te w teście:

when(userFactory.createUser(LOGIN, PASSWORD))
        .thenReturn(new User(LOGIN, PASSWORD));

Niestety (a może stety) nie można ukryć tego wywołania w standardowym outpucie, chyba że się napisze własna implementację InvocationListener’a.

W wywołaniu #2 widzimy, że wywołano metodę validate() z parametrem "password" i zwrócono zero. Co prawda metoda ta zwraca void, ale to pierdoła i nie należy się nią przejmować. Co fajniejsze, to po kliknięciu na AccountService.java:19 zostaniemy przeniesieni w miejsce wywołania tej metody. Bardzo użyteczny feature.

Trzecia interakcja jest analogiczna, ale za to czwarta jest ciekawa. Widzimy z jakimi parametrami wywołano mockowaną metodę, z którego miejsca w kodzie i gdzie zostało to zachowanie zdefiniowane! Od razu można przejrzeć konfigurację testu i się zorientować co skąd się bierze. Jak komuś za mało / za dużo, to zawsze można samemu sobie zaimplementować InvocationListener'a. Dzięki temu można trochę lepiej poznać bebechy tej biblioteki.

To tyle odnośnie tej logowania interakcji w Mockito. Obyście musieli jej używać jak najrzadziej, gdyż jak dla mnie świadczy to o skomplikowaniu i zagubieniu we własnych kodzie. Warto jednak o czymś takim zawczasu wiedzieć, może czasem uratować tyłek. Mi dzięki temu udało się dojść co było nie tak.

Cały kod wykorzystywany w tym wpisie można ściągnąć z githuba, a prezentowany kod testowy znajduje się w klasie: AccountServiceTestWithMockInvocations.

Morał tej historii:
Zwracaj uwagę na to co i jak mówią inni i nie daj się zmanipulować! Zwłaszcza w pracy :)

Kolejny Code Retreat

Dzisiaj wziąłem po raz kolejny udział w imprezie spod znaku Code Retreat. Tym razem odbył się on w Wolfsburgu – czyli mieście największego europejskiego koncernu samochodowego. Zorganizowany został on przez znajomych z pracy, a sponsorem była firma T-Systems on site.

Podczas początkowych sesji mogłem podzielić się swoją wiedzą z zakresu programowania w parach, TDD, baby steps, pisania dobrych testów i znajomości IDE. Nie ma się tu co rozpisywać, bo ciekawsze działo się później.

Postanowiłem wykorzystać obecność fanatyków Scali i trochę się poduczyć tegoż języka. Zdobyta wiedza przyda się przy realizacji kursu: Functional Programming Principles in Scala. Kto się jeszcze nie zapisał, ma jeszcze szansę. Więcej o kursie można poczytać na scala.net.pl. Podczas mojej pierwszej scalowej sesji, udało mi się sporo samemu napisać i odświeżyć jakieś stare wiadomości na temat tego języka. Część wymagań nawet działała. Szkoda jednak, że Eclipse dalej kuleje w tym temacie. Mam nadzieję, że z Ideą będzie lepiej.

Podczas mojej drugiej sesji skalowej programowałem razem z jeszcze większym wyjadaczem (fanatykiem) tego języka. Było więc co chłonąć. Podczas tej sesji (w ogólności) ćwiczyliśmy pisanie bez pętli, co w Scali nie jest jakimś utrudnieniem. Udało nam się całą logikę zakodować wraz z testami i bez pętli, w czasie krótszym niż 45 minut i z wyjaśnieniem mi, jak działa ta cała magia! Co chwilę wlepiałem swoje ślepia w ekran, dziwiąc się, co ‘to’ lub ‘tamto’ robi, oraz próbując zrozumieć, czy to aby na pewno pokrywa wszystkie wymagania. Jestem pod bardzo dużym wrażeniem tej sesji. Teraz trzeba na spokojnie (albo pod wpływem ;) ) poznać wykorzystane mechanizmy tegoż języka, aby móc je później efektywnie stosować.

Wyniesione doświadczenie z tej sesji, pozwoliło mi jeszcze podczas ostatniego sparowania, ponownie zakodować wszystkie reguły gry. Czasem lubię się droczyć, z moimi partnerami podczas Code Retreat. Zwłaszcza przy ping pongu staram się tak odbić piłeczkę, aby się później dużo nie narobić, a jedynie obserwować, jak ktoś się męczy. Tym razem coś poszło nie tak, gdyż sam musiałem się napocić. O dziwo udało się po raz drugi dojść do końca, bez większych problemów, że coś nie działa i nie wiadomo dlaczego. Dodatkowo nie można było rozmawiać podczas tej sesji, co stanowiło dodatkowe utrudnienie. Spotkałem się z nim po raz pierwszy i przekonałem się, ile rzeczy można przekazać niewerbalnie.

Podsumowując wypadło super. Był to mój 6ty CodeRetreat (licząc te oficjalne jak i te zamknięte). Obiad był na wypasie, ciepły z dużymi możliwościami wyboru dania i z deserem. Również było sporo owoców (zamiast ciasteczek) i możliwość zjedzenia śniadania (jak ktoś nie zdążył rano). Ważnym punktem (który był strzałem w dziesiątkę) była Club Mate. Pomogła ona zebrać siły na ten jakże wyczerpujący wysiłek intelektualny, jakim jest Code Retreat. Nieźle się naYerbałem, a w ogólnym rozrachunku, to cała skrzynka poszła. Uważam, że napój ten, powinien wejść do formuły Code Retreat ;)

Teraz pozostaje już tylko czekać, na drugi Global Day of Coderetreat, który w tym roku przypada 8 grudnia. Rok temu 94 miasta wzięły w tym udział, a cel na ten rok to 200 miast. Zobaczymy czy się uda i jak spędzę ten dzień.

Code Retreat w Berlinie

W Niedzielę 3ciego czerwca wziąłem udział w warsztatach Code Retreat w Berlinie. Był to mój nie pierwszy udział w tego typu „imprezie”, ale pierwszy raz było to za granicą i w otwartej formie jednoczenie (wcześniej zorganizowaliśmy sobie CR w pracy). Co mnie bardzo zaskoczyło to wielka różnorodność kulturowa. Spodziewałem się, że event będzie prowadzony w języku niemieckim, ale jak się okazało w Berlinie mieszka sporo ludzi, którzy nie mówią w tym języku. Z drugiej strony, jak się okazało, łatwiej jest mówić o typowo technicznych sprawach w języku angielskim.

Pierwszą sesję kodowałem z Carlosem z Portugali. Przykładowo on mimo prawie rocznego już tutaj pobytu nie używał Niemieckiego, a w pracy oficjalnym językiem jest angielski, ze względu na sporą różnorodność kulturowa. Kodowaliśmy w Rubym, tzn. miałem okazję zobaczyć jak to można robić i poznać podstawy podstaw, ale ogółem nic konkretnego. Generalnie w Portugalii jest podobna sytuacja jak w Polsce, tzn. projekty są, praca jest, ale lepiej być gdzieś indziej.

Druga sesję miałem okazję po kodować z Grzegorzem Dziemidowiczem. W końcu była możliwość się poznania i sprawdzenia się przy klawiaturze. Była to moja najbardziej produktywna sesja podczas tego dnia jak i chyba podczas wszystkich Code Retreat’ów w jakich brałem udział. Obaj dobrze się poruszaliśmy po IntelliJ IDEA, była super komunikacja, zbliżone pomysły na design (czyli nie wiele konfliktów) i szybka ewolucja designu (ekstrakcja osobnych klas dla żywych i umarłych komórek, przeniesienie do nowych klas odpowiednich implementacji).

Udało mi się sprzedać fajnego hotkey’a do Idei. Mianowicie zamiast pisać assercję, można napisać warunek, jaki chcemy sprawdzić (tak jak by to był zwykły if), zaznaczyć tekst, wcisnąć Alt + Enter i wybrać opcję „Create JUnit Assertion”, aby zamienić porównanie w wywołanie odpowiedniej metody. Screen poniżej.

Podczas kolejnej sesji (tym razem z Łukaszem Balamutem) jak drugi raz pokazywałem ten skrót, to odkryliśmy, że nie zawsze on działa. Teraz jak to sprawdzałem, to doszedłem do tego, że jak zaznaczymy tekst od lewej do prawej, to popup pokazuje się bez tej (i innych opcji). Na szczęście ktoś już zgłosił ten błąd: IDEA-86707.

Z Łukaszem ćwiczyliśmy pisanie w Javie, przy czym na napisanie testu mieliśmy tylko dwie minuty. Jak stoper dochodził do końca, a my nie zdążyliśmy skończyć testu, to trzeba było usunąć kod i zacząć od nowa. Później analogicznie robiliśmy z implementacją. Ćwiczenie to miało na celu tworzenie małych prostych testów i prostej implementacji. Mi się kilka razy nie udało skończyć testu, gdyż nie była to moja klawiatura i bardzo ciężko mi się tworzyło test „na szybko”. Dla mnie pisanie testu, to czas w którym intensywnie myślę, co chcę testować, jak, jaką nazwę dobrać i czy test jest poprawny. Dwie minuty to troszkę za mało, nawet jak test jest niewielki.

Później trochę się posprzeczaliśmy na temat używania słówka should na początku nazwy każdej metody testowej. Łukasz twierdzi, że kiedyś było test (bo musiało być), a teraz ten „noise” zamieniliśmy na should i jak czytamy nazwy niedziałających testów, to i tak pomijamy ten prefiks.

Później wyskoczyliśmy całą grupą na obiad. Poszliśmy na jakieś burgery w pobliskim bistro. Panie z za lady bardzo się zaskoczyły nagłym zmasowanym atakiem żądnych mięsa programistów w Niedzielę, gdyż wcześniej nikogo w tym barze nie było. Co prawda nie była to pizza, ale taki lepszy fast food, smaczny i sponsorowany przez Nokię. Była w tym czasie możliwość pogadania z innymi uczestnikami.

Po obiedzie miałem jeszcze okazję pokodować z Janem. Tym razem rozmawialiśmy po Niemiecku.

Ostanie dwie sesje były bardzo szalone. Postanowiliśmy zrobić coś, z czym spotkałem się pierwszy raz. Mianowicie 6 par postanowiło zacząć kodować w Javie i wykonywać rotację jednej osoby co 10 minut. Do tego nie skasowaliśmy kodu pomiędzy sesjami. Bardzo smutne było, gdy trafiałem co chwila na tą samą trefną implementację jednego z uczestników, jednak ciężko było mi przeforsować jemu inny sposób spojrzenia na problem i odpuściłem. Ciężko, zwłaszcza podczas drugiej sesji, przebiegało wdrożenie w to, co się dzieje w projekcie, gdyż przez 10 minut ktoś musiał wytłumaczyć / pokazać w którym miejscu jesteśmy, jak to implementujemy i coś dopisać. W momencie gdy udało się już dopchać do klawiatury, to przychodziła już nowa osoba na sąsiednie stanowisko i role się odwracały.

O dziwo prowadzący stwierdził, że pierwszy raz widział, że ludzie podczas ostatniej sesji są tak mocno ożywieni. I rzeczywiście tak było. Te częste rotacje powodowały, ze trzeba było dawać z siebie wszystko, a stres z tym związany na pewno powodował wydzielanie się motywująco – pobudzających substancji w naszym ciele.

Na koniec oczywiście retrospekcja z całego dnia, podziękowania, wymiana kontaktami i wypad na piwko. Tam to dopiero całość spływa z człowieka i można jeszcze pogadać w luźniejszej atmosferze. No i jeszcze było sporo dzielenia się wrażeniami z Marcinem Saneckim i Rafałem w drodze powrotnej.

Podziękowania dla sponsorów @nokia, @crealytics, @klosebrothers. Miejsce odbywania się imprezy było ciekawe, gdyż znajdowało się w niezbyt uroczej dzielnicy, a blok wyglądał jak była fabryka. Za to firma crealytics udostępniła małe przytulne biuro i Club Mate, które trzymało mnie cały dzień na nogach. Powinni wprowadzić ten napój w pracy obok / zamiast kawy. Ogółem organizacja była bardzo dobra, dojście oznaczone, a na ścianach wisiały ciągle reguły gry.

Podsumowując, poznałem ciekawą technikę wymiany rotacyjnej uczestników co 10 minut, z którą nie spotkałem się wcześniej. Podpatrzyłem kilka innych konwencji nazywania metod testowych i zorientowałem się jak wygląda praca w Berlinie (miasto start-up’ów), gdzie dominującym językiem jest angielski.

Migracja z EasyMock’a na Mockito

Dostałem wczoraj w projekcie zadanie zmigrowania testów korzystających z EasyMock’a na Mockito. Zadanie to przypadło mi, ponieważ jakiś czas temu udało mi się wprowadzić do projektu Mockito, co uważam za duży sukces, gdyż jak wiadomo inicjowanie zmian w projektach nie jest łatwe.

Poniżej przedstawiam jak mi poszło.

9:00 Zbudowałem projekt, odpaliłem testy i zapisałem ile ich jest.
9:02 Sprawdziłem, że mam tylko 3 testy wykorzystujące EasyMock’a. W tym momencie stwierdziłem, że nie ma co szukać w Google jakiegoś migratora, ściągać, instalować i zastanawiać się, jak go uruchomić. Przy tak nie wielkiej liczbie klas do zmiany szkoda zachodu i lepiej zrobić to prymitywną metodą Search & Replace.
9:16 Skończyłem migrować 1wszą klasę.
9:19 Po przyjrzeniu się klasie zrobiłem jeszcze refaktoring, bo jak nie teraz to kiedy? Później nigdy nie nadejdzie.
9:20 Zacząłem modyfikować następną klasę.
9:27 Zakończyłem migrację i refaktoring. Wziąłem się za ostatnią klasę.
9:34 Ukończyłem modyfikacje dla 3ciej klasy.
9:35 Uruchomiłem wszystkie testy – działa.
9:41 Usunąłem wpisy dotyczące EasyMock’a w pom’ach Mavenowych. Tutaj przydała się funkcjonalność „Szukaj w plikach”, jaką daje Notepad++, abym mógł wyszukać wszystkie wpisy.
9:42 Odpaliłem builda i testy w Eclipse - zakończone sukcesem.
9:43 Odpaliłem builda i testy za pomocą konsoli – również zakończone sukcesem.
9:44 Rozpocząłem proces synchronizacji z repozytorium.
9:46 Zmiany zacomitowane.
9:52 Wystartował build na serwerze CI.
10:00 Build zakończył się jednym fail’ujacym testem. Dziwne, bo lokalnie działało. Jako że nie mam dostępu do konfiguracji Jenkinsa to i tak bym nie zidentyfikował problemu. Podszedłem do problemu pragmatycznie: usunąłem nadmiarowe wywołanie verify() i nieużywanego Mocka w jednym teście.
10:08 Rozpocząłem synchronizację z repozytorium.
10:11 Zmiany zacomitowane.
10:12 Wystartował kolejny build.
10:23 Build zakończony sukcesem, banan na ustach, można iść na herbatę.

Na całe szczęście mój obecny projekt jest jeszcze we wczesnej fazie wytwarzania, więc nie było dużo do roboty. Przy czymś większym, gdzie EasyMock jest namiętnie używany, łatwiej było by napisać jakiś skrypcik robiący brudną robotę za nas. Dodatkowo mój zespół ma niewielką wiedzę odnośnie używania mock’ów (i pisania dobrych testów), więc mam kogo ewangelizować :)

Poniżej jeszcze prezentuję przekształcenia z jakich korzystałem. Nie jest to oczywiście pełen zestaw, ale może on stanowić zajawkę Waszych migracji, albo może pomóc zrozumieć różnice między tymi bibliotekami.

import static org.easymock.EasyMock.createMock; import static org.mockito.Mockito.mock;

createMock mock

import static org.easymock.EasyMock.expect; import static org.mockito.Mockito.when;

expect when

andReturn thenReturn

import static org.easymock.EasyMock.verify; import static org.mockito.Mockito.verify;

Elementy do usunięcia: import static org.easymock.EasyMock.replay; replay

Do rozpatrzenia:
Przy wywołaniach verify() trzeba dopisać metodę z argumentami jaka powinna się wywołać. Albo jeszcze lepiej zastanowić się nad sensownością testu, gdyż często verify() jest zbędne. Ponadto anyTimes() zazwyczaj trzeba usunąć.

Na więcej problemów nie natrafiłem, ale zdaję sobie sprawę z tego, że przy większym systemie, gdzie EasyMock jest namiętnie wykorzystywany, może nie być tak łatwo. Przy okazji migracji można od razu wyłapać testy które są niedobrze napisane lub są niepoprawne z punktu widzenia Mockito, np. wywołanie verify() przed testowaną metodą.

Nowa ksiazka o testowaniu jednostkowym

Dnia 28 marca 2012 pojawiła sie oficjalnie książka: Practical Unit Testing with TestNG and Mockito napisana przez Tomka Kaczanowskiego. Wspominałem w jednym z poprzednich wpisów (na temat testowania wyjatków), że ta książka nadchodzi. Już oficjalnie jest dostępna do kupienia na practicalunittesting.com do czego zachecam.

Dlaczego o tym pisze?

Powodów jest kilka.

Po pierwsze jest to książka polskiego autora (co prawda po angielsku, ale spolszczenie jest w przygotowaniu), a tych należy wspierać. Łatwiej (podobno) jest napisać książkę techniczną po angielsku i później ją przetłumaczyć na nasze, niż pisać po polsku i później się męczyć.

Po drugie jest to kompletny, uporządkowany i aktualny zbiór technik z przykładami, jak pisać dobre testy. Książka wyjaśnia wszelkie wątpliwości związane z nazewnictwem, konwencjami i dobrymi praktykami, jak i daje wiele cennych wskazówek.

Dla kogo jest ta książka?

Książka jest bardzo dobra dla osób, które chcą właśnie zacząć pisać testy jednostkowe do swojego kodu i nie wiedzą jak wystartować. Książka wprowadza krok po korku do lepszego świata kodu pokrytego testami. Również dla startych wyjadaczy znajdzie się sporo cennych informacji. Dalsze rozdziały książki omawiają zaawansowane zagadnienia ze świata testowania. Tomek wskazuje również dobre praktyki jak pisać testy, a także prezentuje narzędzia powiązane z nimi(jak catch-exception czy testy mutacyjne).

Dlaczego więc się wypowiadam o tej książce, skoro dopiero co się ukazała?

Dobra, dość tej krypto reklamy, czas na konkrety ;)

Powodem dla którego piszę na blogu o tej książce, jest fakt, że brałem udział w jej powstawaniu. Mianowicie robiłem korektę (review) książki, za co dostałem podziękowania uwiecznione na jednej ze stron w książce:

In various different ways a number of people have helped me with writing this book – some by giving feedback, others by comforting me in times of doubt.
Marcin Stachniuk was the first person to offer to review the book in the early stages of its being written, and at the same time the most persistent of my reviewers. He read every part of the book and gallantly overcame the obstacles I frequently put in his way: frequent releases, constant juggling of the contents, minor piecemeal adjustments, etc.

Nadszedł teraz czas podzielenia się moimi wrażeniami ze wspólnej pracy z autorem.

Wszystko zaczęło się na konferencji GeeCON 2011 w Krakowie, Podczas (za)ostatniego dnia konferencji (tzw. Community Day) Tomek miał swoją prezentację pt.: Who watches the watchmen? - on quality of tests. Na prezentacji trochę się wynudziłem, gdyż otarłem się już o większość omawianych tam zagadnień. Pod koniec jednak prelegent pochwalił się, że właśnie pisze książkę o testach. Wówczas jeden z uczestników (nazwisko do wiadomości redakcji) zaproponował, że chętnie by zrobił review jego książki. Bardzo zaciekawiła mnie ta inicjatywa, i mimo iż wszyscy już wychodzili z sali, zostałem chwilę dłużej, aby przysłuchać się rozmowie na temat recenzowania książki.

Tomek zaproponował aby chętni się do niego zgłosili mail’owo, aby ustalić szczegóły współpracy.  I tak to się zaczęło. Stwierdziliśmy, że najlepszą formą wymiany informacji będzie założona na Google prywatna grupa dyskusyjna, poprzez którą Tomek będzie podsyłać nowe wersje książki. Tym kanałem można również podyskutować i wyjaśnić ewentualne kwestie sporne. Rozwiązanie to sprawdziło się.

Preferowanym sposobem zgłaszania uwag, było odsyłanie aktualnego pdf’a ze wstawionymi komentarzami w teksie, w formie żółtych karteczek. Funkcjonalność taką daje nam Foxit Reader. Dzięki temu Tomek widział dokładnie, którego miejsca dotyczy uwaga. Było to również wygodne dla mnie, gdyż fragmenty czytałem na ekranie komputera. Niektórzy zgłaszali swoje uwagi w postaci wiadomości na grupie, ale dla mnie żółte karteczki i tak były lepsze, gdyż dokładniej wskazywały miejsce, gdzie jest coś nie tak.

Na podstawie e-maili naliczyłem jakieś 20 „release’ów” książki, tzn. fragmentów, które Tomek podsyłał do korekty. Początkowo przychodziły pojedyncze rozdziały do czytania, ale lepszym wyjściem, jak się później okazało, było podsyłanie całości. Dzięki temu nie było rozdziałów wyrwanych z kontekstu i było widać ogólnego zarys całości książki, w którą stronę ona dąży.

Koleje wersje pojawiały się z różną częstotliwością. Czasem było kilka w tygodniu, a czasem była cisza przez dłuższy czas. Ale to już była kwestia Tomka jak sobie organizuje pracę nad książką. Ze swojej strony mogę powiedzieć, że często nowe wersje się pojawiały, jak akurat mocno byłem zajęty innymi sprawami i niemiałem możliwości aby usiąść od razu do lektury. Kilka razy dogoniła mnie kolejna wersja i wtedy już trzeba było się zmobilizować i przeczytać to co tam Tomek naskrobał :)

Co do zgłaszanych uwag, to Tomek zazwyczaj je akceptował. Jak nie widziałem poprawy w następnej wersji, to początkowo się czepiałem, że moje sugestie są nieuwzględniane, ale w późniejszym czasie doszedłem do wniosku, że nie powinienem się tym przejmować. W końcu to książka Tomka i Jego koncepcja, a nie moja. Jedynie sprawy edytorsko/estetyczne (zła czcionka, rozjeżdżające się tabelki) były dla mnie bardzo irytujące, ale to chyba przez spędzenie dawniej sporej ilości czasu z LaTeX’em. Tomek postanowił zostawić to sobie na sam koniec, przez co ciągle widziałem te niedoskonałości. To była chyba jedyna pierdółka, która mi troszkę przeszkadzała w naszej współpracy.

Moje zaangażowanie zostało wynagrodzone cytowanymi wyżej podziękowaniami w książce (Dzięki Tomek!). Właściwie to nie nawet nie ustaliliśmy szczegółów współpracy, tzn. co ewentualnie będę z tego miał. Do samego końca nie wiedziałem nawet, czy pojawią się te podziękowania w książce (po cichu na nie liczyłem). W końcu w jednej z ostatnich wersji książki zobaczyłem, że są :) Świadczy to o tym, że moje zaangażowanie było kompletnie non-profit.

Podsumowując współpracę cieszę się, że wziąłem udział w tym przedsięwzięciu. Było to bardzo ciekawe doświadczenie i mogłem przez to poznać proces powstawania książki. Robienie review sprawia wielka frajdę, czego zwieńczeniem jest oczywiście ukazanie się książki „na produkcji”. Szczerze polecam każdemu zaangażowanie się w tego typu akcję.


Btw. Co do relacji z 33 degree (kilka osób już o nią pytało), to musi ona jeszcze poczekać kilka dni, z powodu natłoku innych zajęć (w tym korekty ostatecznej wersji książki Tomka), jak i obecnych sporych zmian życiowych.

Testowanie wyjątków

Testowanie wyjątków w testach jednostkowych od zawsze trochę mnie irytowało. Niby sprawa banalna, ale jak do tego dołączymy słynny szablon // given // when // then to nie bardzo wiadomo gdzie powinniśmy umieścić słówko // then, aby test był dalej przejrzysty.

Problem nie jest nowy. Zastanawiano się nad dobrym rozwiązaniem już podczas prezentacji Bartosza Bańkowskiego i Szczepana Fabera pt. Pokochaj swoje testy [czas - 18.04] na Wroc JUG, albo pewnie jeszcze wcześniej. Idąc za radą lepszych, zawsze korzystałem z try / catch’a, aby wiedzieć gdzie dokładnie spodziewam się wyjątku.

@Test
public void shouldThrowSomeException() throws Exception {
    // given
    SomeClass someClass = new SomeClass();

    try {
        // when
        someClass.doSomething();
        fail("This method should throw SomeException");
    } catch(SomeException e) {
        // then
        assertThat(e.getMessage()).isEqualTo("Some message");
    }

}

Blok instrukcji try / catch wymusza na nas pewien sposób formatowania kodu i przez to nie do końca widać gdzie jest // when i // then. Można oczywiście próbować umieszczać je w trochę innym miejscu, np. // when przed try, a // then przed fail().

@Test
public void shouldThrowSomeException() throws Exception {
    // given
    SomeClass someClass = new SomeClass();

    // when
    try {
        someClass.doSomething();
        // then
        fail("This method should throw SomeException");
    } catch(SomeException e) {
        assertThat(e.getMessage()).isEqualTo("Some message");
    }

}

Jednak rozwiązanie dalej jest nie do końca czytelne. Gdyby jeszcze nic nie umieszczać w bloku catch, to już w ogóle, trzeba się chwilę zastanowić, co my tu tak na prawdę chcemy przetestować. Całe szczęście narzędzia do statycznej analizy kodu dbają o to, aby nie zostawiać pustych bloków catch.

Alternatywnym rozwiązaniem dla testowania rzucanych wyjątków, jest stosowanie andotacji @Test z parametrem expected w JUnit’cie  :

@Test(expected = SomeException.class)
public void shouldThrowSomeException() throws Exception {
    // given
    SomeClass someClass = new SomeClass();

    // when
    someClass.doSomething();

    // then
    fail("This method should throw SomeException");
}

Test wygląda już lepiej, ale ma swoje wady. Jak mi jakiś test nie przechodzi, to pierwsze co robię, to czytam sekcję // then testu. W tym przypadku widzę wywołanie fail() co sugeruje mi, że test zawsze powinien nie przechodzić. Dopiero po chwili zauważam, że test został zadeklarowany jako @Test(expected = SomeException.class), czyli spodziewam się wyjątku typu SomeException. Jest tutaj jednak pewne niebezpieczeństwo. Jeżeli faza // given testu, czyli przygotowania środowiska testowego, będzie trochę dłuższa, to może się zdarzyć, że tam gdzieś poleci wyjątek. Test będzie dalej przechodził, a tak naprawdę nie będzie testowane to co chcieliśmy. Wspominał o tym już Szczepan Faber w cytowanym fragmencie video. Dodatkowo nie można, jeśli byśmy chcieli sprawdzić np. treść komunikatu wyjątku. Z tych względów nie stosowałem tej konstrukcji.

Sprawa wygląda trochę  lepiej w przypadku TestNG. Tutaj mamy analogiczna adnotację, mianowicie zamiast expected używamy expectedExceptions.

@Test(expectedExceptions = SomeException.class,
        expectedExceptionsMessageRegExp = "Some Message.*")
public void shouldThrowSomeException() throws Exception {
    // given
    SomeClass someClass = new SomeClass();

    // when
    someClass.doSomething();

    // then
    fail("This method should throw SomeException");
}

Tu jeszcze dochodzi fajna zabawka w postaci expectedExceptionsMessageRegExp, czyli możemy za pomocą wyrażeń regularnych sprawdzić, czy wyjątek posiada spodziewaną wiadomość. Dalej jednak istnieje ryzyko wyrzucenia tego wyjątku w sekcji // given.

Podobną zabawkę daje nam JUnit, ale w trochę innym wydaniu. Mianowicie od wersji 4.7 można zastosować ExpectedException:

public class SomeClassTest {

    @Rule
    public ExpectedException thrown = ExpectedException.none();

    @Test
    public void shouldThrowSomeException() throws Exception {
        // given
        thrown.expect(SomeException.class);
        thrown.expectMessage("Some Message");
        SomeClass someClass = new SomeClass();

        // when
        someClass.doSomething();

        // then
        fail("This method should throw SomeException");
    }
}

Tutaj w klasie testowej musimy zdefiniować regułę (linie 3 i 4), która początkowo mówi, że nie spodziewamy się wyjątków. Natomiast już w naszych metodach testowych, redefiniujemy to zachowanie i mówimy, czego się spodziewamy w danym teście (linie 9 i 10). Możemy dzięki temu sprawdzić komunikat rzucanego wyjątku. Tutaj jednak podajemy fragment wiadomości, którą ma zawierać nasz wyjątek. Istnieje również przeciążona wersja tej metody, która jako argument przyjmuje Matcher’a Hamcrest’owego.

Do niedawna były to jedyne rozwiązania, jakie były dostępne w temacie testowania wyjątku. Jakiś czas temu jednak pojawiła się ciekawa biblioteka: catch-exception. Kod napisany za jej pomocą może wyglądać tak:

@Test
public void shouldThrowSomeException() throws Exception {
    // given
    SomeClass someClass = new SomeClass();

    // when
    caughtException(someClass).doSomething();

    // then
    assertThat(caughtException())
            .isInstanceOf(SomeException.class)
            .as("Some Message");

}

Czyli mamy metodę CatchException.catchException(), gdzie jako argument przekazujemy obiekt naszej klasy. Następnie wywołujemy metodę, którą chcemy przetestować. Na koniec w sekcji // then sprawdzamy czy otrzymaliśmy wyjątek, którego się spodziewaliśmy. Bezargumentowa wersja caughtException() zwraca wyjątek rzucony przez ostatnią klasę, którą przekazaliśmy do metody caughtException(). W naszym wypadku jest to ostatni wyjątek wygenerowany przez someClass.

I to rozwiązanie mi się podoba. W sekcji // when informuję, że będę łapał wyjątki, a w sekcji // then sprawdzam czy poleciał ten wyjątek, którego oczekiwałem. I do tego nie bruździ to przy formatowaniu kodu i użyciu // given // when // then. I mamy czytelny kod :)

Zafascynowany tą biblioteką postanowiłem zajrzeć do środka (kod jest dostępny na googlecode.com), aby zobaczyć jak zbudowano takie rozwiązanie.

public class CatchException {

    public static <T> T catchException(T obj) {
        return processException(obj, Exception.class, false);
    }

}

Czyli mamy delegację pracy do metody processException(), która zwraca obiekt tego samego typu, jaki został przekazany w argumencie. Dzięki temu możemy używać biblioteki w sposób jaki pokazałem powyżej. Zobaczmy co kryje się za tą metodą:

private static <T, E extends Exception> T processException(T obj,
        Class<E> exceptionClazz, boolean assertException) {

    if (obj == null) {
        throw new IllegalArgumentException("obj must not be null");
    }

    return new SubclassProxyFactory().<T> createProxy(obj.getClass(),
            new ExceptionProcessingInterceptor<E>(obj, exceptionClazz,
                    assertException));

}

Po upewnieniu się, że argument nie jest null’em tworzymy (jak można się domyśleć po nazwach) proxy dla naszej klasy. Brnąc dalej w las, jeżeli klasa nie jest ani prymitywem, ani finalna, to proxy tworzone jest  w ten sposób:

proxy = (T) ClassImposterizer.INSTANCE.imposterise(
        interceptor, targetClass);

czyli wykorzystywany jest ExceptionProcessingInterceptor z poprzedniegu listingu, wewnątrz którego znajduje się następująca metoda, gdzie już widać całą magię:

public Object intercept(Object obj, Method method, Object[] args,
        MethodProxy proxy) throws Throwable {

    beforeInvocation();

    try {
        Object retval = proxy.invoke(target, args);
        return afterInvocation(retval);
    } catch (Exception e) {
        return afterInvocationThrowsException(e, method);
    }

}

Metoda beforeInvocation() czyści ostatnio złapany wyjątek, np. z wywołania poprzedniej metody. Następnie w bloku try wywoływana jest nasza rzeczywista metoda (linia 5), a następie zwracana jest (w naszym sposobie wykorzystania biblioteki) wartość wygenerowana przez oryginalną metodę. Jak coś pójdzie nie tak, to w bloku catch jest zapamiętywany rzucony wyjątek (zajmuje się tym metoda afterInvocationThrowsException()). Bardzo sprytny sposób na łapanie wyjątków, a jaki banalny zarazem.

Z ciekawostek jeszcze, to biblioteka korzysta z Mockito, a dokładniej cglib. Nie działa ona z klasami finalnymi (gdyż dla nich nie można teoretycznie tworzyć proxy), no chyba że skorzystamy w PowerMock’a i odpowiednich adnotacji w deklaracji klasy testowej:

@RunWith(PowerMockRunner.class)
@PrepareForTest({ SomeClass.class })
public class SomeClassFinalPowerTest {
    // ...
}

Wtedy zadziała :)



Na koniec wpisu, jeszcze informacja skąd się dowiedziałem o tej bibliotece. Mianowicie powstaje teraz ciekawa książka o testach: Practical Unit Testing with TestNG and Mockito. Pisana jest ona przez Tomka Kaczanowskiego i już niedługo ujrzy światło dzienne. Książka poszła już do recenzji do Szczepana Fabra, więc lipy nie będzie. Będzie można się z niej dowiedzieć m.in. o catch-exception, jak i o testach mutacyjnych, o których pisałem ostatnio. Na razie wyjdzie wersja angielska, ale będzie też robione tłumaczenie na nasz ojczysty język. Zachęcam więc do śledzenia informacji o książce jak i do jej zakupu.

Więcej informacji o tym jak powstawała książka w kolejnych wpisach.

Testowanie mutacyjne z PIT Mutation Testing

Przeglądając dzisiaj (a właściwie to wczoraj) blogosferę natrafiłem na ciekawy post Tomka Kaczanowskiego First Glance At PIT Mutation Testing Tool na temat testowania mutacyjnego, za pomocą nowej biblioteki PIT Mutation Testing. Co to jest testowanie mutacyjne to można poczytać na Wikipedii: Testowanie mutacyjne (co ciekawe w tej chwili dostępny jest tylko artykuł w wersji angielskiej i polskiej).

PIT modyfikuje w locie nasz kod produkcyjny, puszcza testy i sprawdza, czy mutacje kodu są wykrywane przez nasze testy. Sprawdzamy dzięki temu jakość naszego kodu testowego, a dokładniej to, jak ściśle zdefiniowaliśmy zachowanie naszego kodu produkcyjnego za pomocą testów. Jest to trochę więcej niż pokrycie kodu testami wyrażone w procentach, gdyż raport ten podpowiada nam co jeszcze należało by przetestować.

Tomek stworzył przykładowy projekt i umieścił na github’ie. Ściągnąłem go, odpaliłem i przeglądnąłem raporty wygenerowane przez PIT’a. Jako że jest to prosty projekt na potrzeby testu tej biblioteki, postanowiłem zastosować go do swojego projektu MFCCChart. Co prawda nowej funkcjonalności do tego projektu już nie dodaję, ale się nim zabawiam testując jakieś ciekawe rozwiązania.

Patrząc na to co może PIT na stronie Mutation testing systems for Java compared w końcowej sekcji: Summary Of Mutation Testing Systems, to narzędzie to nie ma bezpośrednio wsparcia dla Ant’a, ale mamy interfejs linii komend. Przygotowałem więc komendę, dostosowaną do moich potrzeb:

java -cp out\test\MFCCChart;out\production\MFCCChart;testlib\junit-4.8.jar;testlib\mockito-all-1.8.5.jar;testlib\pitest-0.24.jar;lib\forms_rt.jar;lib\jcommon-1.0.16.jar;lib\jfreechart-1.0.13.jar org.pitest.mutationtest.MutationCoverageReport --outputFormats XML,HTML --reportDir reportspitests --targetClasses org.bitbucket.mstachniuk.mfccchart.* --targetTests org.bitbucket.mstachniuk.mfccchart.* --sourceDirs src --verbose --excludedMethods hasCode,equals --excludedClasses org.bitbucket.mstachniuk.mfccchart.view.*,org.bitbucket.mstachniuk.mfccchart.presenter.*

Najpierw mamy definicję naszego classpath’a. W katalogu out\test\MFCCChart mój ant’owy skrypt budujący wrzuca skompilowane testowe klasy, a do: out\production\MFCCChart klasy produkcyjne aplikacji. Następnie dołączyłem wszystkie wymagane do uruchomienia aplikacji jak i testów biblioteki. Klasa org.pitest.mutationtest.MutationCoverageReport jest klasą startową projektu PIT, a dalej mamy już argumenty dla tejże aplikacji. Ja zapragnąłem raportu w dwóch formatach (XML i HTML) w katalogu reportspitests. Następnie zapodałem klasy, które mają być mutowane, testowe klasy, kody źródłowe (aby można było zobaczyć gdzie wprowadzano mutacje). Jako że jest to biblioteka, której jeszcze nie znam to warto spojrzeć na szczegóły działania (opcja --verbose)  i wyłączyłem z testowania metody hasCode() i equals(), a także klasy z pakietów, które są odpowiedzialne za GUI i spinanie całości (do kupy).

Początkowo miałem problem z opcjami --outputFormats i --excludedClasses, gdyż nie chciały mi działać. Zgłosiłem nawet błąd na stronie projektu: Issue 23, ale szybko się okazało, że podczas kopiowania flag ze strony z Command Line Quick Start Notepad++ zamias zwykłego myślnika wstawił znak wyglądający niemal tak samo, ale o innym kodzie (najprawdopodobniej z po za zestawu ASCII).

Jak już się przekonałem, że generacja raportów działa, postanowiłem dorzucić tą analizę do skryptu budującego aplikację. Początkowo próbowałem to wykonać za pomocą taska exec ale nie chciało hulać. Po za tym task ten jest zależny od systemu operacyjnego i zarzuciłem go na rzecz taska java. I teraz poszło lepiej:

<target name="pitests">
    <java jvmargs="-Xmx600m" fork="true"
            classpath="${mfccchart.testoutput.dir};${mfccchart.output.dir};${basedir}/lib/jcommon-1.0.16.jar;${basedir}/lib/jfreechart-1.0.13.jar;${basedir}/lib/forms_rt.jar;${basedir}/testlib/junit-4.8.jar;${basedir}/testlib/mockito-all-1.8.5.jar;${basedir}/testlib/pitest-0.24.jar"
            classname="org.pitest.mutationtest.MutationCoverageReport"
            args="--reportDir reportspitests --targetClasses org.bitbucket.mstachniuk.mfccchart.* --targetTests org.bitbucket.mstachniuk.mfccchart.* --sourceDirs src --verbose --excludedMethods hasCode,equals --excludedClasses org.bitbucket.mstachniuk.mfccchart.view.*,org.bitbucket.mstachniuk.mfccchart.presenter.* --outputFormats XML,HTML">
    </java>
</target>

Bez fork'a nie chciało mi działać (zresztą pewnie jak większość tego typu rozszerzeń wywoływanych z Ant'a) Co mogłem to pozamieniałem na ścieżki zdefiniowane w pozostałej części skryptu. Jeszcze podaję sporą ilość ścieżek do konkretnych bibliotek co mi się nie podoba. Podejrzewam, że jest lepszy sposób na to ale mistrzem Ant’a nie jestem. Jak by ktoś wiedział, to proszę o komentarz.

Teraz czas na analizę raportu: „Detected 84 of 93 mutations”. Czyli na 9 różnych mutacji podatny jest mój kod. Patrząc na pokrycie klasowy, to chyba bardzo dobrze to wypadło:

Mutated classes	Line coverage	Mutation coverage
OneMfccFileStatistic	100%	85%
MfccFileReader	100%	97%
FrameInformation	100%	100%
ChartSettings	100%	100%
MfccFrame	100%	100%
StatisticTableModel	100%	80%

Ja jestem zadowolony z wyniku. Jak ktoś chce to niech sobie przejrzy mój przykładowy raport: MFCCChart_pit_reports_201201080158.zip

Teraz pozostaje tylko rozkminienie czego ode mnie chce ten raport (czyli co jeszcze mogę poprawić w swoich testach), jak i przyjrzenie się konkurencyjnym rozwiązaniom, których zestawienie można obejrzeć na wspominanej już stronie: Mutation testing systems for Java compared.