Post Category → programming

Po spotkaniu z TestNG

Pierwsze w tym roku spotkanie Szczecińskiej Grupy Użytkowników Java‘y jest już za nami ;). Prelekcję o TestNG przeprowadził Filip „Filus” Pająk.

Testowanie, a zwłaszcza TDD jest bardzo popularnym tematem w środowisku Java’owym ale nie o samym testowaniu była mowa tylko o alternatywie dla JUnit jaką jest TestNG.

Muszę się przyznać, że z testowaniem jestem dość na bakier (ale staram się to zmienić). Po prezentacji Filipa jestem trochę przerażony ogromem możliwości TestNG. Wielokrotne powtarzanie testów, organizowanie ich w grupy, możliwość tworzenia zależności pomiędzy grupami, testowanie równoległe oraz rozproszone … i wiele więcej! Informacji była cała masa! Do tego sporo przykładów (dobrze, że będą są umieszczone na stronie JUG’a)! A wszystko to podane w dość telegraficznym skrócie … bo jak inaczej nazwać jeden przykład per feature? Ale taki był zamysł autora, żeby dać nam ogląd na całość tego ogromnego framework’a i moim zdaniem się jemu to udało!

Po całej prezentacji pozostał we mnie jakiś wewnętrzny nie dosyt spowodowany tym, że mimo jest to rewelacyjna technologia, mimo że ciągle się słyszy wkoło TDD, mimo że naprawdę jestem świadom korzyści płynących z testowania jednostkowego (i nie tylko) … to ciągle nie mogę wprowadzić w życie modelu TestFirst, trzeba będzie nad tym popracować mocno …

Ciekaw jestem czy jeszcze ktoś w tym roku będzie chciał się zaprezentować przed Szczecińskim JUG’iem … może Ty ? 😉

Szczecin JUG – Filip Pająk o TestNG

Dla tych co nie są subskrybentami do mailing listy SzJUG‘a, a znajdują się w okolicy Szczecina (lub w samym Szczecinie) i są zainteresowani posłuchaniem o TestNG przytoczę maila Leszka:

Witam ponownie,

zapraszam Was w imieniu swoim i Filipa na spotkanie, które będzie poprowadzone przez właśnie niego, którego tematem będzie “Nie tylko JUnit. O TestNG słów parę a nawet kilka.”

Filus jest cudownym (bo osiągnięcie tego zakrawało na cud) absolwentemkilku etapów powszechnej edukacji, w tym Wydziału Informatyki Politechniki Szczecińskiej. Od pięciu lat zawodowo udziela się jako programista jawy, a od lat dwóch z kawałkiem próbuje swych sił także jako tester oprogramowania. Pewnie dlatego Los postawił go przed nieuchronnym spotkaniem z TestNG, a o wrażeniach z tego rendez-vous, a nawet może tête-à-tête, chętnie poplotkuje w miłych gronie szczecińskiego JUG-a.

Do wygrania licencja na jeden z wymienionych produktów firmy *JetBrains*:

a. IntelliJ IDEA Personal License
b. ReSharper Personal License
c. TeamCity Build Agent
d. Ruby Mine

oraz

licencja na agenta JVM *JRebel* you could try these out.
Miejsce: WI ZUT (PS), sala 200

Godz. 18:00

Data: 22.04.2010
Serdecznie zapraszamy!

Ja będę tam na pewno, a Ty ? 😉

EGit development

Nie będę ukrywał, że jestem fanem zarówno Eclipse‘a jak i Git‘a. Idealnym połączeniem obu faktów jest projekt EGit, czyli (jak by ktoś jeszcze nie wiedział albo się nie domyślał) wtyczka dodająca obsługę repozytoriów Git’a do Eclipse’a.

Jakiś czas temu opisywałem EGit’a. Wtedy to już zauważyłem brak kilku opcji w UI. Jedną z nich była np. obsługa tagowania … ale już tak nie jest (a właściwie to nie będzie), gdyż wczoraj wysłałem do Code review efekt kilku godzin mojej pracy. Jeżeli patch zostanie zaaplikowany to w najnowszej wersji EGit’a będzie można już swobodnie tagować i zmieniać nazwy tagów prosto z UI.

BTW. Nie jest to mój pierwszy patch w tym projekcie, kilka dni temu zostały zaakceptowane moje poprawki do jednej z klas w EGit’cie 😉 W zanadrzu mam jeszcze coś … ale o tym za jakiś czas dopiero ;>

Git, EGit i Gerrit …

Podczas prac nad moją pracą inżynierska mam przyjemność używać git’a jako systemu kontroli wersji. Żeby współpraca układała się „zgrabniej” używam wtyczki do Eclipse‘a EGit znajdującej się w inkubatorze Eclispe Fundation (kilka dni temu zdarzyło się mi popełnić mały artykuł na temat EGit’a).

W naszej współpracy brakowało mi pewnych dwóch małych wodotrysków w dialogu do wybierania gałęzi, mianowicie reakcji na podwójne kliknięcie w nazwę gałęzi oraz poruszania się po drzewie za pomocą kursorów. Pomyślałem sobie, że warto by było chłopaków wesprzeć w pracy, w końcu odwalili kawał dobrej roboty … tak więc stworzyłem odpowiednią poprawkę. Niby nic wielkiego … do czasu … okazuje się projekt ten używa rozbudowanego narzędzia do przeglądania (review) i współtworzenia (conribute) kodu no i właśnie tutaj znajduje się problem … ale do rzeczy.

Gerrit, jest rozbudowanym (przynajmniej z mojego punktu widzenia) narzędziem do zarządzania rozproszonym projektem. Wymusza on pewien system pracy. Każdy patch musi zostać przejrzany oraz oceniony zanim trafi do głównego repozytorium. Nad każdą poprawką odbywa się głosowanie; dopiero po uzyskaniu odpowiedniej liczby głosów (od osób uprawnionych) zostanie ona włączona do głównej gałęzi kodu. Dodatkowo każdą linie poprawki można skomentować co ułatwia współpracę w rozproszonym zespole, zwłaszcza z nowymi jego członkami. Wprowadzane poprawki do poprawki ( 😉 ) np. na podstawie komentarzy, są widoczne w jednym miejscu. Całość od strony interfejsu wygląda ładnie i przejrzyście (osobiście nie miałem najmniejszych kłopotów żeby się „połapać” w tym web’owym interfejsie).

Projekt EGit udostępnia dokumentację ułatwiającą rozpoczęcie współpracy z Gerrit’em. Bezproblemowo przez nią przebrnąłem, stworzyłem potrzebne konto, dodałem klucz publiczny, odpowiednio skonfigurowałem Git’a dodając hook‘i … więc można zaczynać zabawę. ;>

Szybkie ogarnięcie w kodzie, lokalizacja odpowiedniej klasy, chwila google’ania o SWT … i gotowa jest poprawka. Szybki commit do lokalnego repo, potem wypchnięcie tego do Gerrit’a … i oczekiwanie na werdykt developerów ;>

Minęły 3 dni … jest pierwszy werdykt … -1 :|. Z mojego pośpiechu wkradły się dwie literówki błąd dość infantylny … no i nie trzymam standardów formatowania (nie potrzebnie ujmuję w klamry jedno-instrukcjowe linie w if’ach i else’ach). Trzeba to poprawić … no i tutaj właśnie zaczęły się strome schody …

Zrobiłem poprawkę, commit, push … Gerrit zamiast dodać tą poprawkę do już istniejącej wyodrębnił to jako zupełnie osobną zmianę … nie tak się umawialiśmy, nie tak miało być.

Jak się po chwili okazuje, EGit nie wspiera hook’ów … w ogóle ich nie używa tak więc w moim commit’cie zabrakło jednej bardzo ważnej linii:

Change-Id:

Teraz muszę to jakoś ręcznie połączyć …

Nie równa walka trwała dwie czy trzy godziny … w tym czasie za-spamowałem trochę skrzynki mailowe commit‘erą, bo dostają maila o każdej nowej poprawce zgłoszonej do systemu, a ja takich nie prawdziwych poprawek podczas walki wprowadziłem :/. Na szczęście całość zakończyła się sukcesem. Tak więc co zrobić jeżeli wypchniemy do Gerrit’a naszą zmianę bez Change-Id i chcemy do niej wprowadzić poprawkę ?

Najpierw musimy się na pewno znajdować w odpowiednim miejscu historii Git’a. Tak więc na początku tworzymy sobie nową gałąź i przełączamy się na nią (oczywiście wszystko robimy z linii poleceń):

git branch fixes
git checkout fixes

Za pomocą git log znajdujemy commit który wypchnęliśmy do repozytorium, niech to będzie np. f4a33b1 (wystarczy 6 pierwszych znaków z SHA-1) i cofamy się w czasie:

git reset –hard  f4a33b1

Dokonujemy potrzebnych zmian, za pomocą git add dodajemy nasze zmiany do commit’a i (ważne), poprawiamy ostatni commit (czyli ten f4a33b1):

git commit –amend

Najlepiej w samej treści wiadomości dołączonej do commit‘a nic nie zmieniać, zatwierdzamy commit wychodząc z edytora. Teraz ponownie odpalamy git log i zapisujemy/zapamiętujemy 6 pierwszych znaków z nowego commit’a (na pewno będą różne od poprzednich), np. ee421a. Wypychamy naszą poprawkę do repozytorium

git push ssh://username@egit.eclipse.org:29418/egit.git ee421a:refs/for/master

Po chwili powinniśmy dostać maila potwierdzającego wprowadzenie zmian.

Uff, to na tyle. Być może jest na to lepszy sposób … ale ten na pewno działa (a nie chcę wystawiać cierpliwości developerów EGit’a na zbyt dużą próbę).

BTW. Ten post starałem się pisać bez zbędnych anglikanizmów … wyszło to raczej średnio, nie mogłem skojarzyć odpowiedniego polskiego odpowiednika dla commit oraz hook.

JGit + EGit = Eclipse Git support

Jakiś czas temu projekty jgit (czyli implementacja git‘a w java’ie) oraz egit (plugin do eclipse’a dodający wsparcie dla git’a) znalazły się w inkubatorze fundacji Eclipse. Dawno temu wyczytałem nawet, że git ma zastąpić CVS‘a na miejscu domyślnego systemu kontroli wersji w IDE … ale zanim to nastąpi upłynie pewnie jeszcze sporo czasu … nie mniej jednak już teraz można podejrzeć jak się mają rzeczy, co też właśnie w uczynię ;).

Może na początek kilka numerków 3.5.2 oraz 0.6.0.201002030558, nie nie są to numery dużego lotka ;). Pierwszy oczywiście opisuje aktualną wersje stabilną Eclipse, drugi zaś jest numerem wersji egit/jgit.

Pierwotnie stroną domową obu projektów było jgit.org (tutaj też znajduje się update site dla eclpse‘a) ale po przejściu projektu pod skrzydła Eclipse Fundation dostępne są dwie stronki eclipse.org/egit/ oraz eclipse.org/jgit/ na obu w sekcji download znajdziemy ten sam link do update site’u:

http://download.eclipse.org/egit/updates

Ja używam ciągle starego update site‘u:

http://www.jgit.org/updates

Z tego co sprawdziłem to podana wcześniej wersja jest dostępna tylko w drugim repo, możliwe że jest to jakiś nightly build czy coś “nie stabilnego” … nie wiem, u mnie działa ;>

W tym wpisie chciał bym omówić jak “podłączyć” nowy projekt pod git SCM (zakładając, że wcześniej nie współdzieliliśmy go w żadnym SCM‘ie). Jeżeli chodzi natomiast o dodanie istniejącego już projektu podpiętego pod jakieś git‘owe repo to robi się to przez File -> Import, nie ma do tego nowej perspektywy wszystko robią wizard‘y.

Tak więc dla przykładu zakładamy sobie nowy projekt GitTest, dodajemy tam jedną klasę Main z “standardowym”

System.out.println("Hello git!");

Następnie na tak spreparowanym projekcie klikamy prawym myszy i wybieramy po kolei Team -> Schare Project… z dostępnej listy oczywiście wybieramy git. Jeżeli plugin znajdzie w jakimś katalogu nadrzędnym katalog .git (czyli miejsce gdzie git przechowuje swoje metadane) to zasugeruje podpięcie się pod już istniejące repo. W moim przypadku taka sytuacja nie występuje.

Zaznaczmy nasz projekt, klikamy w Create Repository, następnie w Next i oto wykonaliśmy odpowiednik git init … sam nie wiem co jest prostsze, chyba jednak wolał bym to zrobić z “palca”.

Skoro już zainicjalizowaliśmy nasze repo trzeba by je czymś wypełnić, czyli wykonać odpowiednik git add. Spokojnie, wszystko można wyklikać 😉 tak wiec zaczynajmy klikać ;>. Parawym myszy na pliku/katalogu który chcemy dodać (w moim wypadku jest tylko jeden katalog src) i poklei Team -> Add to version control.

Kolejny krok to git commit. Znowu to wyklikamy ;> Team -> Commit. Możemy teraz dodać komentarz do commit‘a jak również odznaczyć pliki które nie chcemy dodać do repo. Po kliknięciu w Commit nasze zmiany zostaną zapisane w repozytorium.

Jako że przez pomyłkę na dodałem cały projekt do commita (Team -> Add to version control) również “nie chciane pliki” takie jak .setting, .classpath oraz .project dodały się co commit‘a. W takim wypadku odpalamy widok Navigator i na każdym takim pliku wykonujemy po kolei operację Team -> Remove from version control, Team -> Add to .gitignore. Tak powstały plik .gitignore dodajemy do git‘a i commit‘ujemy (czyli: Team -> Add to version control, Team -> Commit).

Pora zrobić coś bardziej szalonego … zmieńmy zawartość Main.java ! Żeby za bardzo nie szaleć ja dodałem dodatkowy wykrzyknik na końcu “Hello git!” ;>. Zapisujemy zmiany. Eclipse automatycznie (podobnie z resztą jak to ma miejsce podczas korzystania z CVS‘a) informuje nas o tym, że względem repozytorium nasz plik jest zmieniony. Jak sprawdzić zmiany ? Nie ma czegoś takiego jak Synchronize with repository … ale jest za to: Compare with -> Git index. Moje „szalone zmiany” są widoczne jak na dłoni … albo jak kto woli “jak na CVS’ie” 😉

Niestety na chwilę obecną nie dopatrzyłem się żadnych możliwości porównania całego projektu, jak to jest możliwe w CVS’ie. Trzeba porównywać każdy plik z osobna … jest to trochę męczące ale mam nadzieje, że w kolejnych wydaniach taka funkcjonalność zostanie “jakoś” zaimplementowana oraz dodana.

Po sprawdzeniu jakie zmiany, względem repo, wprowadziliśmy w naszym projekcie możemy śmiało wyklikać Team -> Commit na naszym zmienionym pliku. W ten sposób moje repo zawiera już 3 commit‘y ;>

Może teraz sobie po-branch‘ujemy. Prawie standardowo klikamy na projekt i wybieramy Team -> Branch… wyskakuje nam okienko w którym możemy dodać nową gałąź, zmienić jej nazwę oraz przełączyć się na wybraną gałąź. Aktualna gałąź jest pogrubiona oraz dodatkowo oznaczona przypisem (current). Klikamy w New branch nazwa jest praktycznie dowolna, ja nazwałem nowy branch jako “awesome-changes” ;), akceptujemy zaznaczamy nowo dodany branch i klikamy Checkout, żeby się na niego przełączyć. Prawda, że proste ? 😉

Teraz jeżeli klikniemy na projekt prawym myszy i z menu wybierzmy Team -> Show in Resource History widzimy historię zmian w naszym projekcie.

Niestety na chwilę obecną plugin nie pozwala merge‘ować branch‘y … szkoda, trzeba to robić ręcznie z linii poleceń czyli git merge <target> <source>.

Dostępna jest natomiast opcja nadpisywania poczynionych zmian. Przez Team -> Reset można wykonać reset wprowadzonych zmian do poziomu w wskazanej gałęźi.

To tyle mojego małego przeglądu, więcej informacji można znaleźć w User Guide EGit‘a.