Znacie ten moment, kiedy chcecie coś szybko sprawdzić, a okazuje się, że proste rzeczy wcale nie są takie proste? Potrzebowałem przeanalizować raport pokrycia kodu z JaCoCo. Nic wielkiego – odpalić parser, wyświetlić raport w komentarzu do PR. Jest do tego wiele akcji na gh – np. https://github.com/marketplace/actions/jacoco-report Problem w tym, że Gradle domyślnie generuje raporty […]
Podwójnie parametryzowane testy w Spocku
Jakiś czas temu wymieniałem implementację autoryzacji w systemie nad którym pracuje. Jednym z wymagań było zapewnienie poprzedniej funkcjonalności. Oczywiście mieliśmy testy na poprzednią funkcjonalność ale w jaki sposób użyć ich do testowania innej implementacji? W tym poście przedstawię tę historię. Spock podobnie jak inne frameworki do testowania wspiera parametryzowane testy. Zazwyczaj definiuje się je przez […]
O typowanych nilach
W tym wpisie chciałbym naświetlić jak w Go wygląda sprawa z pustym wskaźnikiem i jakie to ma konsekwencje oraz jak można to naprawić przy użyciu generyków. Zacznijmy od podstaw W Go wszystko ma typ oraz wartość. Brzmi to rozsądnie bo mamy silnie typowany język więc wszechobecne typy nie powinny nas dziwić. Zgodnie ze specyfikacją języka […]
10 Praktycznych Testów ArchUnit dla Aplikacji Spring
Do efektywnego wytwarzania oprogramowania niezbędne jest kontrolowanie jego jakości, w szczególności architektury i struktury kodu. W języku Java z pomocą może przyjść ArchUnit, biblioteka, która pozwala testować pewne aspekty architektury oraz designu. W artykule przedstawię dziesięć praktycznych zastosowań testów ArchUnit, opartych na moich doświadczeniach z rozwijaniem aplikacji opartej o Spring Framework.
Mandelbrotowska natura modularyzacji
W świecie oprogramowania, modularyzacja ma kluczowe znaczenie dla utrzymania elastyczności, skalowalności i czytelności kodu. Uczestniczyłem w wielu dyskusjach na temat tego, jaki rozmiar powinien mieć moduł. Padają w nich często skrajne opinie, począwszy od „lepszych jest kilka dużych modułów”, po „im mniejsze moduły, tym lepiej”. Prawda jak zawsze leży gdzieś pośrodku, a w tym wpisie wskażę, jak ją namierzyć.
Modularyzacja i testy architektury
Modularyzacja w projektach stanowi jedną z kluczowych technik, które pozwalają na zachowanie czytelności, skalowalności oraz łatwości w utrzymaniu kodu. Wraz z rozwojem projektów, zwłaszcza tych o większym zakresie, staje się ona ważnym elementem zapewniającym porządek i przejrzystośći w strukturze kodu. Jednakże, wraz z rozwojem projektu, gdy wprowadzane są kolejne zmiany, a programiści przychodzą i odchodzą, łatwo zapomnieć o początkowych założeniach architektury. Z pomocą przychodzą testy automatyczne. Tylko co testować i jak je zrobić? Bez solidnych testów nie jesteśmy w stanie upewnić się, że nasza struktura modułowa spełnia założenia, które sobie postawiliśmy.
Mroczne strony Open-Closed Principle
Zasada otwarte-zamknięte (Open-Closed Principle), opisana w SOLID, zapewnia elastyczność projektu, jednak czy zawsze prowadzi to do optymalnego, gotowego na przyszłe zmiany kodu? Brzmi ona obiecująco – otwarte na rozszerzenie, zamknięte na modyfikację. Przyjrzyjmy się jej bliżej.
Monolit mentalny: Testy E2E
W ostatnich latach architektury usługowe, a w szczególności mikrousługi, zdobyły ogromną popularność, tymczasem podejście do testów end-to-end (E2E) często pozostało bez zmian. Słyszymy, że testy sprawdzające działanie całego systemu są kluczowe w procesie tworzenia oprogramowania, zwłaszcza przy architekturach rozproszonych. Pojawiają się stwierdzenia w stylu „Musimy udowodnić, że system działa jako całość. Kiedyś mieliśmy monolit i testy E2E, teraz mamy niezależne mikrousługi, więc testy E2E są tym bardziej potrzebne”.
Dokumentacja nie jest wymaganiem
W swoim życiu zawodowym wielokrotnie spotkałem się z wytycznymi wedle których ,,każdy system musi posiadać dokumentację”. Zwykle na podstawie tak sformułowanych wymagań ktoś z zespołu przygotowywał dokument, który nazywano dokumentacją. Nierzadko był to wymuszony dokument, którego istnienie niczego nie zmieniało w kontekście użyteczności systemu i niczego nie ułatwiało.
W tym poście chciałbym przedstawić moje trzypunktowe podejście do zadań i problemów związanych z dokumentacją.
Przepis na Word Clock po polsku
Biuro mojej poprzedniej firmy znajdowało się w Hamburgu. Od czasu do czasu wpadałem tam w delegację. Ponieważ siedziba mieściła się w dość ekskluzywnej dzielnicy HafenCity po drodze do biura mijałem różne galerie i sklepy. W jednym na witrynie postawiony był taki zegar. Od razu zwrócił moją uwagę (tym bardziej że wcześniej czytałem o tym na […]