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.