Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: Splatch, dodany: 03.09.2008 09:28, tagi: framework

W nawiązaniu do poprzedniej noty o CXFie, którą napisałem jakiś czas temu, gonię aby uzupełnić brak konfiguracji klienta. Sam proces jest bardzo zbliżony do tworzenia klienta w oparciu o XFire. Nie jest wymagana duża ilość kodu Javy, a w zasadzie tylko dwa pliki XML (client.xml, myservice.xml).

Pierwszy z nich odpowiada za wczytanie wymaganych rozszerzeń CXFa oraz definicję bazowej konfiguracji fabryki z interceptorami. W interceptorach możemy skonfigurować logowanie, obsługę załączników czy standardów WS-Security etc. Wszystkie te ustawienia będą dziedziczone, a fabryki docelowych usług będą dodawać tylko adres, do odpytywania. Na koniec bean klienta będzie miał określony autowire by nie przekazywać mu wszystkich własności.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Splatch, dodany: 02.09.2008 18:51, tagi: framework

Okładka książki Temat testów jednostkowych nie pojawiał się na tym blogu tak często jak PHP czy JAXB, jakkolwiek temat ten poruszałem w 2 notach - o testach oraz o singletonie.

Tych, którzy chcieliby dowiedzieć się więcej o testach na przykładzie JUnit i Javy zapraszam się do zapoznania z bardzo dobrą pozycją na temat testów jednostkowych, z którą miałem przyjemność się zetknąć.

JUnit. Pragmatyczne testy jednostkowe w Javie to tłumaczenie książki Pragmatic Unit Testing in Java z serii The Pragmatic Programmers. Nie wspominam tu o tej książce jak i całej serii przypadkowo, ponieważ pragmatyzm jest główną domeną tego bloga.

Tytuł ten traktuje o rzeczy bardzo ważnej, jaką są bez wątpienia testy jednostkowe. Nie jest to sucha referencja opisująca możliwości JUnit ale przewodnik i poradnik - czyli nie tylko o tym czym testować ale po co i w jaki sposób to robić. Sam język w którymś momencie schodzi na drugi plan a ważna staje się na prawdę idea i szczytny cel, jakim jest wykluczanie błędów przed wdrożeniem aplikacji, tak by nie musiał się o nich w ogóle dowiadywać klient.

W książce znajduje się wiele przykładów i rozważań, pisanych lekkim językiem, całość czyta się lekko i przyjemnie. Jest to bodajże najczęściej wypożyczana pozycja z mojej domowej biblioteczki. W każdej kolejnej pracy (a troszkę ich w międzyczasie było :)) staram się komuś polecić tą pozycję i odzew jest zawsze pozytywny, co dowodzi, że praca autora włożona w tytuł była bardzo przemyślana. Z najważniejszych elementów, które zostają w książce omówione należy wymienić definiowanie warunków brzegowych, wykorzystanie “obiektów imitacji” (ang. mock objects) z użyciem biblioteki Easy Mock oraz projektowanie kodu przyjaznego dla testów. Chyba wszyscy się ze mną zgodzą że są to elementy nieodzowne podczas tworzenia testów.

Na zakończenie przytoczę dwa akapity które najbardziej zapamiętałem z całej pozycji.

Gdyby architekci sprawdzali mosty w taki sam sposób jak większość programistów to na świeżo wybudowanym moście środkiem jezdni przejeżdżałby jeden malutki samochód w ciepły dzień, bez jakiegokolwiek wiatru i innych zakłóceń atmosferycznych. (o warunkach brzegowych)

Z testami jednostkowymi jest jak ze strzyżeniem trawnika. Jeśli jest on dobrze utrzymany to jego uporządkowanie nie jest zadaniem trudnym. Jeśli jednak nasz trawnik zarośnie (w projekcie nie będzie testów jednostkowych) i pojawią się chwasty (błędy) to jego uporządkowanie (wprowadzenie testów) będzie zadaniem bardzo czasochłonnym. (o filozofii testowania)

Koniec końców, siejąc pragmatyczną propagandę na rzecz testów :), zachęcam wszystkich do zapoznania się z opisywaną książką. Dla praktyków zawiera ona kilka trafnych spostrzeżeń a dla laików będzie znakomitym sposobem na wdrożenie się w temat testów.

Szkic tej noty czekał na publikację ponad rok, stąd może być on troszkę nieskładny.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.