Wolkan na Pomorzu, czyli o XIX Spotkaniu SJUGi

Chwała!

W poprzedni czwartek, osiemnastego dnia października, w Strefie 89 odbyło się kolejne, dziewiętnaste już, spotkanie szczecińskiej jugi. Tym razem prelegentem był Paweł Stawicki, a tematem bliższe zapoznanie przybyłej Publiczności ze Spockiem. Wyjątkowo, nie było to spotkanie autorskie Leonarda Nimoya, a przedstawienie używalności podbudowy do testów jednostkowych.

W trakcie dość chybkiej prezentacji (około pół godziny) mogliśmy się dowiedzieć, że w zasadzie jest to „nakładka” na JUnit. Nakładka, która wspierając się możliwościami Groovy pozwala ułatwić pisanie testów. Tak więc ja osobiście, jako wielki fan TestNG, za bardzo „praktycznie” skorzystać z prezentacji, nie skorzystam. Funkcjonalne oraz elastyczne przewagi TestNG nad rozwiązaniami opartymi na Junit są po prostu obecnie dla mnie zbyt duże, żeby dla drobnych fajerwerków z nich rezygnować. Swoją drogą ciekawym jest wciąż wielka „monopolizacja” „rynku” testów przez JUnit w środowisku jawowym.
Wracając do prezentacji, jak już wspomniałem, była dość chybka, bo raz, że temat niezbyt obszerny, dwa, że prezenter sprawnie pokazał, to co miał pokazać. Z tego co pamiętam zdarzyła się jedna, drobna wpadeczka, z przypadkiem gdy coś podczas asercji miało nie działać, ale zadziałało. Bywa. Poza tym istotnie nie było się czego przyczepić. No może, na upartego, można by wytknąć, że może parę rzeczy to raczej zasługa grooviego niż Spocka samego w sobie, ale z drugiej strony, czy to takie ważne w praktyce? Nie wydaje mi się, więc się nie czepiam ;)
Podsumowując, prezentacja całkiem, całkiem jeśli chodzi o warsztat, niekoniecznie porywająca jeśli chodzi o temat. Przy zastrzeżeniu, że dla osób za podstawę mających zestaw TestNG plus Groovy. Zaś dla dżejjunitowców mogę podejrzewać, że mogłoby być to nawet małe „łał”. Bo muszę przyznać, że o ile prezentacja utwierdziła mnie w przekonaniu co do podjętego parę lat wyboru, to również, acz przy założeniu, że pamięć w temacie nieszwankuje, Spock wydaje się przeciekawą alternatywą do czystego JUnita i praca z nim może być mniej frustrująca.

P.S. Ach, bym zapomniał! Prezentacja była nagrywana, więc zostaje nam poczekać cierpliwie na efekty montażu i udostępnienie materiałów.

No i z głowy, czyli parę słów po osiemnastce Jugi.

Chwała!

W ostatni czwartek miałem przyjemność (znaczy się ja miałem przyjemność, czy słuchacze to już ich pytać ;)) zaprezentować się z wykładem na XVIII spotkaniu Szczecińskiej JUGi. Poniżej zamieszczam tę parę slajdów, natomiast zbiór kodów z przykładami znajdziecie tutaj.

Teraz zaś trochę przemyśleń. Chyba udało się:

• przedstawić to co zamierzałem,
• przedstawić to co oczekiwał Publiczność,
• nie zanudzić tejże na śmierć
• i samemu nie dostać pomidorem w twarz.

Nie udało się zaś:

• zmieścić w czasie (dwie godziny zleciało)
• nie potknąć się gdzieniegdzie

• nie uśpić nikogo z Publiczności (pozdrawiam niniejszym kolegę z kanapy ;))

Jeśli zaś macie jakieś uwagi, to walić śmiało w komentarzach jak w bęben, wszelka krytyka (byle konstruktywna) mile widziana na drodze do perfekcji.

XVIII Spotkanie Szczecińskiej JUGi. Zaproszenie.

Chwała!

Lato mija nam powoli, ruch na drogach po wakacjach już się wzmógł niestety, trzeba także troszkę rozruszać bloga (ale nie za bardzo coby szoku jakiego nie było). Na szczęście natrafiła się okazja, gdyż już w najbliższy czwartek, 20. września 2012 roku, o godz. 18, w gościnnych progach szczecińskiej Strefy 89, spróbuję przedstawić Wam pokrótce język Groovy.

Jak Szanowni Czytelnicy pewnie wiedzą, język ten tak mi się przewija przez bloga od czasu do czasu, co może sugerować, że nawet go używam od czasu do czasu. Jest więc szansa, że coś mającego sens uda mi się przekazać.

W założeniach ma być przegląd składni i możliwości języka wraz z najbliższym ekosystemem. Ponieważ temat jest powierzchniowo ogromny (o paru aspektach języka można, wydaje mi się, zrobić osobne prezentacje), więc przede wszystkim ma stanowić bazę do własnego przemyślenia, a nie dania konkretnej odpowiedzi na konkretne problemy. Przykro mi, ale od tego (myślenia) nie uciekniecie ;)

Na koniec przypominam, że to i tak tylko przystawka przed prezentacją Amorfisa na temat Spocka :D

Tłumne zgromadzenie inspiruje, czyli o lekko bajeranckim testowaniu krotek słów kilka

Chwała!

Jak uważni, stali Czytelnicy wiedzą, ledwo co byłem na Najlepszej Z Konferencji. Jednakże któż by przypuszczał, że tak szybko nadarzy się okazja do praktycznego i zarobkowego wykorzystania inspiracji z tego wydarzenia?

Tym razem nadarzyło się wykorzystać zasiane ziarno pomysłów przez Bartka Kuczyńskiego, znanego też pod mianem Koziołka. I właściwie, najbardziej w tym wszystkim zaskakujące było, że sam wcześniej na to nie wpadłem.

 - No dobra, ale może wreszcie ktoś wyjaśni o co się rozchodzi? - zapytacie Państwo. No więc, detalicznie i szczegółowo rozchodzi się o rozwiązanie następującego problemu. Otóż, dostałem do sprawdzenia mechanizm czegoś, co można nazwać generowaniem raportu dla instytucji zewnętrznej. Raport ten jest zestawieniem sumarycznym danych zebranych z kilku tabel, przy różnych również warunkach wyboru odpowiednio od typu rozpatrywanego "głównego obiektu".

Bajeranckie Speca dogadanie się w kwestii ValueRecordera

Chwała!

Tak się czasem składa, że jak dwóch mądrych się spotka to nie idzie im się czasem dogadać w kwestii jakiegoś drobnego szczegółu, bo każdy z nich wie lepiej, a ten trzeci, głupi gwoli ścisłości, tylko się denerwuje, wszak to On traci, a do tego nie rozumie o co detalicznie się rozchodzi.

Taka też sytuacja trafiła mnie ostatnio prosto między oczy. Otóż podbiłem sobie w projekcie wersję Grooviego z 1.7.x do 1.8.x. Na pierwszy (i drugi zresztą też) rzut oka wszystko działa nadal. Jest dobrze, lecimy z koksem dalej. No i dalej przyszło niestety.

Bzycząco pozorowane obiektów wspaniałości.

Sława!

Tak to przypadkiem zupełnym ostatnimi czasy potrzeba mnie naszła napisania paru testów jednostkowych. Ponieważ nieszczęścia parami chadzać lubują, to do potrzeby tej doszła potrzeba upozorowywania obiektów, a że afektem darzę w tym celu podbudowę Mockito, to nie zastanawiając się Mockito w dłoń, hajda na koń, Baśkę uwolnić od zbója! Uwalnianie idzie gładko, Tatarzyn umyka, że kurz wstrzymuje ruch lotniczy na połowie kontynentu, to lecim na Szczecin bez zagrychy. Aż tu nagle jak mi NullPointerException z siurpryzy między oczy nie przydzwoni, aż się moje testy nogami nakryły.

 - O Ty! W ząbek czesany figlarzu! Ładnie to tak zza węgla bez uprzedzenia po zębach przygarowywać? - mu wygarniam, a ten nic, tylko szczerzy się jak głupi do sera i repetę zasuwa. Ale nie takie cwaniaki z nami pogrywać próbowały, czyż nie proszę Szanowego Państwa? Trzeba wziąć ino sprawę rozumowo, a nie sercowem uczuciem. Takoż więc należy się urwipołciowi dokładnie przykapować i detalicznie inspekt przedstawić. Kod mój niniejszym się przedstawia:

ClassImplentingIface ciff = Mockito.mock(ClassImplentingIface.class);

Mockito.when(ciff.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == ciff.doSomething(3);

Gdzie ClassImplementingIface jest klasą w języku groovy, a objawiony wyjątek to:

java.lang.NullPointerException at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at com.blogspot.pacykarz.Testowa.test(Testowa.groovy:19)

Jak widać wyjątek rzuca się już przy konfiguracji stworzonego pozoranta, a śledztwo szczegółowsze wykazuje, iż próba wywołania jakiejkolwiek metody na nim skutkuje podobnym wyjątkiem. Dogłębniejsze rzucenie wzroku narządem i winnego mamy! Otóż jest nim, jakże zacny i szanowany skądinąd, mechanizm mopowania, którego metody w tej sytuacji też są pozorowane przez Mockito i stąd cały ten ambaras. Jak więc wyjść z twarzą i po honorowemu z zajścia?

Sposób pierwszy i niezawodny, to pozorować zamiast klasy jej interfejs(y). Szparko wszystko zaiwania wygalantowanie, że tylko pozazdrościć. Pozazdrościć jeżeli pozorowana klasa nie implementuje interfejsu, który możemy wykorzystać. Co wtedy? Wtedy niestety są ograniczenia i dwudziesty stopień zasilania. Pochylmy się znów nad egzamplą:

//This working always:
Iface mockedIface = Mockito.mock(Iface.class);
Mockito.when(mockedIface.doSomething(Mockito.anyInt())).thenReturn("ReturnedValue");

assert "ReturnedValue" == mockedIface.doSomething(3);
Mockito.verify(mockedIface, Mockito.times(1)).doSomething(Mockito.anyInt());

//This not working with matchers
ClassNotImplentingIface mockedClass = Mockito.mock(ClassNotImplentingIface.class, Mockito.withSettings().extraInterfaces(GroovyInterceptable));

Mockito.when(mockedClass.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == mockedClass.doSomething(3);
Mockito.verify(mockedClass, Mockito.times(1)).doSomething(3);

//This also not working with matchers, but also returns wrong verifications.
ClassNotImplentingIface spiedClass = Mockito.spy(new ClassNotImplentingIface());

Mockito.when(spiedClass.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == spiedClass.doSomething(3);

//Be aware of given 4 times invocation instead of 1!
Mockito.verify(spiedClass, Mockito.times(4)).doSomething(3);

//This also not working with matchers and returns wrong verifications.
ClassNotImplentingIface mockedClass2 = Mockito.mock(ClassNotImplentingIface.class, new Answer() {
  Object answer(InvocationOnMock invocationOnMock) {
      if (invocationOnMock.getMethod().getName() ==~ /.*get.*MetaClass/) {
          return invocationOnMock.callRealMethod();
      } else {
         return null; /* or other default answer*/
      }
  }
});

Mockito.when(mockedClass2.doSomething(3)).thenReturn("ReturnedValue");

assert "ReturnedValue" == mockedClass2.doSomething(3);

//Be aware of given 4 times invocation instead of 1!
Mockito.verify(mockedClass2, Mockito.times(4)).doSomething(3);

Pierwszym obejściem jest dodanie do pozoranta interfejsu GroovyInterceptable, jeżeli możemy sobie na to pozwolić. Istnieje wtedy duże prawdopodobieństwo, że kod testowy będzie działać, z jednym szkopułem. Nie jest możliwe niestety używanie odpowiedników (matcher) z Hamcrest/Mockito, gdyż przy próbie ich użycia, dobrze nam znajomy NPE podstawia hakiem nogie i to tak dyskretnie, że dostajemy dość mylący komunikat o mieszaniu odpowiedników z surowymi typami.

Obejście drugie polega na szpiegowaniu obiektu. Niestety w tym wypadku nie dość, że również nie możemy skorzystać z odpowiedników, to do tego dostajemy wyniki weryfikacji zwiększone o pewien narzut z mopowania, czego mus być świadomym.

Obejście trzecie zaś to użycie przy tworzeniu pozoranta domyślnej odpowiedzi (np. w sytuacji gdy żaden z powyższych konceptów niemożliwy jest do zastosowania). Podobnie jak w drugim, tutaj także brużdżą odpowiedniki i wyniki weryfikacji, a cały myk zaś polega na obsłużeniu wszystkich żądań o metaklasy przez realną, a nie pozorowaną metodę klasy. Kto wie, może nawet mykiem tym dałoby się obsłużyć zastosowanie odpowiedników? Nie upieram się przy stwierdzeniu, że się nie da.

Ostatnim na dziś, czwartym sposobem, bardzo możliwe, że często może być najrozumniejszym, jest użycie innej podbudowy pozoranckiej dedykowanej dla grówiego, np. GMock czy inszego MockFor.