Tag: Java

ArchUnit czy Konsist: testy architektury dla Kotlina

Posiadanie w projekcie testów architektury (architecture tests) powoli staje się czymś oczekiwanym. Użytkownicy Kotlina od niedawna mają problem bogactwa wyboru. Mogą użyć biblioteki ArchUnit, już ustabilizowanej, całkiem szeroko znanej, stworzonej dla Javy, ale działającej też dla Kotlina. Pojawiła się jednak alternatywa. Konsist to narzędzie napisane specjalnie pod Kotlina, o krótszej historii, ale zdobywające popularność.

W dalszej części artykułu porównam ze sobą te biblioteki. Nie będę kopiował haseł reklamowych: zawodowo używam obu od ponad roku, więc mam sporo obserwacji natury praktycznej.

Po lekturze będziesz (mam nadzieję) wiedzieć, czy do twojej sytuacji bardziej będzie pasować ArchUnit, czy też Konsist, a może potrzebujesz obu.

Moim celem jest porównanie, więc nie omówię wszystkich cech obu narzędzi i będę się streszczał. Spragnionym szczegółów na temat konkretnej biblioteki polecam moje wcześniejsze artykuły: wprowadzenie do ArchUnita, wprowadzenie do Konsista.

Artykuł jest skierowany do programistów Kotlina. Jeśli programujesz tylko w Javie, to z Konsista nie skorzystasz, bo obsługuje tylko język od JetBrains. Mimo wszystko, polecam pod uwagę wyliczenie niedostatków ArchUnita – nie podaję tu lepszego narzędzia do Javy, ale moim zdaniem lepiej znać wady swojego narzędzia, niż ich nie znać.

Czytaj dalej

ArchUnit – praktyczne zastosowanie

W artykule o podstawach ArchUnita przedstawiłem, jak i po co pisać testy architektury. Być może znasz temat, ale wciąż nie jesteś do końca przekonany (-a). Lub takie testy masz, ale nie są rozwijane, a nikt nie wie, co i w jakim celu do nich dodawać.

Poniższy tekst dostarcza konkretne, życiowe przykłady użycia. Są to zastosowania z innej bajki niż to, co podaje jako „use cases” oficjalna strona ArchUnita albo clickbaitowe „tutoriale” w stylu tych na Baeldungu (nie linkuję, nic nowego nie wnoszą).

Pokażę, jak stosuję ArchUnita do wykrywania pomyłek w testach. Oraz do wykluczania kodu, który źle działa w Kotlinie: Optional.orElse oraz adnotacji z jakarta.annotation.

Mam nadzieję, że te przykłady pomogą ci lepiej zrozumieć potencjał testów architektury, oraz dostarczą nowych inspiracji do pisania własnych, dostosowanych do potrzeb twojego projektu. Możesz też podany tu kod po prostu skopiować do siebie (udostępniam go na licencji MIT).

Czytaj dalej

Quartz czyli scheduling ze śmietnika historii

Quartz to narzędzie, które jest niestety popularnym wynikiem przy wyszukiwaniu haseł „scheduler”, „job”, „Java”. Strona domowa projektu tytułuje się „Enterprise Job Scheduler”. „Enterprise” ma sugerować, że to rozwiązanie poważne, więcej: skalowalne na duże projekty. W ramach wzbogacenia dyskusji chciałbym dorzucić inną opinię: że Quartz to niebezpieczny szrot, którego nieusuwalne wady mogą zarżnąć waszą produktywność i spowodować incydenty na produkcji.

Przejdziemy od kodu z błędami N+1 zapytań, przez alarmujący stan projektu, do architektury z single point of failure.

Czytaj dalej

Sonar dla Kotlina nie ma sensu

Sonar reklamuje się obsługą Kotlina, ale co reklamy i dokumentacja przemilczają, to bardzo niska użyteczność sugestii, jakie oferuje dla tego języka.

Jeśli ktoś nie wie, o co chodzi: to popularne narzędzie do znajdowania problemów w kodzie. W marketingu pojawia się też jako SonarQube i SonarCloud. Ma opinię sprawdzonego „industry standard”. Jest duża szansa, że jeśli ktoś rzuci problem „potrzebujemy narzędzia do static analysis”, to od razu padnie sugestia „weźmy Sonara”. Czy słusznie? To zależy. Jeśli stawiamy na Kotlina, to nie.

W dalszej części artykułu skupię się na konkretnym zastosowaniu Sonara: do projektów napisanych w Kotlinie. Jeśli szukacie informacji jak odpalić SonarQube dla Javy – przykro mi, nie tu. Co jeszcze będzie? Podam linki, dzięki którym samodzielnie zweryfikujecie aktualną sytuację (nawet w wypadku, gdybym przestał aktualizować ten artykuł). Podzielę się też subiektywnymi wrażeniami o tym, jak deweloperzy i deweloperki Sonara radzą sobie z problemami w integracji z Gradle’em.

Czytaj dalej

Spacja w system properties, małpa i inne zawiłości komendy 'java’

Jest to raczej rzadka sytuacja, ale może zdarzyć się, że potrzebujecie do Javy przekazać system property, w którym jest spacja. Niestety, może być z tym kłopot. Czasem na drodze stoją Dockery, zmienne środowiskowe i shellowe skrypty uruchamiające. Na wypadek tak niekorzystnych warunków zaprezentuję opcję @, która pozwala uciec od shellowych zawiłości i wczytać opcje Javy z pliku.

Czytaj dalej

Zaoranie mockowania w 20 linijkach kodu

– Co znowu?
– To duży błąd, że ludzi uczy się pisania testów, każąc im używać mocków. Przydatność mocków jest bardzo ograniczona. Zazwyczaj powodują jedynie, że test przepuszcza niedziałający kod. Większość tworzonych na co dzień testów w ogóle nie powinna używać mocków.
– Co za wymysły, to jakaś kompletna bzdura! Pokaż dowody!
– Proszę bardzo.

Czytaj dalej

Walidacja kraju czyli ISO 3166 country codes w praktyce

Być może mamy bazę kontrahentów z różnych stron świata. Albo obsługujemy zakładanie konta użytkownika i wymagamy podania miejsca zamieszkania. Nawet jeśli nie pracujemy w Netfliksie, wcześniej czy później pewnie będziemy musieli zająć się przetwarzaniem danych o krajach.

Jak to przechować? Pole typu „dowolny string” spowoduje, że nasi użytkownicy wkrótce wrzucą tam zarówno „United States”, jak i „U.S.”, „U.S.A”, a nawet „Niemcy” (przynajmniej ja przeszedłem przez takie nieprzyjemne odkrycie). Lepszym wyjściem jest reprezentowanie kraju przez jednoznaczny identyfikator. Na szczęście istnieje ogólnie akceptowalny standard, ISO 3316, czyli w dużym uproszczeniu to, co widzimy w URL-ach albo na tablicach rejestracyjnych: „PL” to Polska, „DE” to Niemcy i tak dalej.

W dalszej części bardzo skrótowo objaśnię kody krajów w ISO 3316. Opiszę też, jak zaprogramować walidację poprawności kodów. Proponuję dwie opcje: z użyciem klasy Locale dostarczanej z JVM oraz przez zewnętrzną bibliotekę nv-i18n.

Czytaj dalej

ArchUnit: zapomnij o architekturze, to elastyczny i inteligentny linter

ArchUnit staje się coraz częściej polecanym narzędziem. Tyle że moim zdaniem ludzie skupiają się na zbyt wąskim zastosowaniu. Winę ponosi jak myślę oficjalna strona, która upiera się, że to biblioteka do sprawdzania architektury systemów napisanych w Javie/JVM i straszy diagramami UML. Plus nazwa jest jaka jest, skojarzenia są nieuniknione. Stąd artykuły uczące ArchUnita tłuką do znudzenia przykłady typu wykrywanie cykli zależności i liczenie warstw. Nie mówię, że to zupełnie nieważne rzeczy, ale są bardziej życiowe problemy – a ArchUnit potrafi wykryć znacznie więcej, niż pokazują typowe tutoriale. Warto go poznać, nawet jeśli nie interesuje cię „testowanie architektury”.

ArchUnit pozwala za pomocą fluent API pisać narzucane na kod reguły, które działają szybko i dają jasne komunikaty błędu. Rozumie typy, co jest jego przewagą nad prostymi linterami typu CheckStyle lub ktlint. Operuje na kodzie bajtowym, więc może działać zarówno z Javą, jak i Kotlinem czy Scalą.

Można w ten sposób narzucać spójny sposób pisania („każdy kontroler musi mieć słowo Controller w nazwie”). Być może ważniejsza jest możliwość zabezpieczania się przed niepoprawnym korzystaniem z zewnętrznych bibliotek. Przykladowo, złe użycie adnotacji frameworku JUnit spowoduje, że kod testu zamiast chronić przed regresją nie będzie nigdy odpalony. Podobne pułapki czyhają w wielu bibliotekach i warto się przed nimi zabezpieczyć.

This article is also available in English.

Czytaj dalej

Czas Mavena minął

Aż ciężko uwierzyć, jak mocno ludzie potrafią trzymać się rozwiązań, które kiedyś podbijały rynek i ułatwiały życie, a obecnie są już tylko groteskowym reliktem przeszłości i hamulcem rozwoju. Japończycy cały czas używają faksów, Amerykanie czeków, a programiści Javy — Mavena. Od razu trochę sprostuję, żeby nie być niesprawiedliwym w ocenach: przywiązanie do czeków może nie być takie złe, bo zapewne nie pozwala na społeczne wykluczenie ludzi, którzy mają kłopoty z nauczeniem się korzystania z komputerów lub są zbyt biedni, żeby z łatwo z nich korzystać. Skupmy się jednak na programowaniu.

Czytaj dalej

Funkcyjna obsługa błędów w Kotlinie i Javie

Czasem obsługa błędów jest prosta, „zerojedynkowa”: albo operacja się powiedzie, albo rzuci wyjątkiem. Mamy jednak też sytuacje, gdy od strony biznesowej podejście „wszystko albo nic” nie ma sensu i oczekiwane jest działanie w trybie „best effort”. Na wejściu jest zestaw danych, wykonujemy na nich operacje, jeśli w trakcie pojawiają się błędy, to po prostu idziemy dalej i próbujemy doprowadzić do końca tak wiele, jak się da, nie wycofując się z niczego. Nie mówimy o beztroskim ignorowaniu błędów: nawet jeśli zgadzamy się na częściowe niepowodzenie, dobrze jest wiedzieć, które z danych były przetworzone pomyślnie, a które z błędem. Jak zaprogramować takie podejście w sposób czytelny i jasno przekazujący intencję?

Imperatywne podejście (try-catch) w naturalny sposób modeluje sytuację zerojedynkową. Żeby zamodelować wersję „best effort” musimy myśleć w sposób bardziej funkcyjny, potraktować zarówno operację do wykonania jak i błąd jako byty na równi z danymi. Będziemy „kolekcjonować” błędy, żeby móc później zanalizować, ile ich było.

Języki nastawione na programowanie funkcyjne ułatwiają tu sprawę, ponieważ mają sprawdzone i dobrze opisane rozwiązania. Przykładowo Scala ma w bibliotece standardowej typ Try. Kotlin i Java nie są językami tradycyjnie wykorzystywanymi w sposób funkcyjny — nie oznacza to, że nie da się działać w nich w analogiczny sposób, jedynie to, że może być trudno znaleźć odpowiedź, jak do tego podejść.

Czytaj dalej