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 […]
Dodatkowe checki w checkstyle
Checkstyle to potężna biblioteka, która nie tylko pozwala ustandaryzować formatowanie kodu w projekcie, ale także wyłapać niektóre błędy w programie (np. czy implementując metodę equals zaimplementowano także metodę hashcode) oraz design kodu (np. maksymalny rozmiar metod lub złożoność cyklomatyczną). To, że narzędzia statycznej analizy kodu są niezwykle przydatne, traktuję jako pewnik. Warto ich używać, nawet […]