Tag: archunit

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

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