Java Developer? Przejdź na wyższy poziom wiedzy 🔥💪  Sprawdź

Team Leader? Podnieś efektywność swojego zespołu 👌 Sprawdź

Zasady pisania dobrych testów – F.I.R.S.T. i konkretne techniki żeby je zastosować

Zasady pisania dobrych testów – F.I.R.S.T. i konkretne techniki żeby je zastosować

Istnieją ogólnie przyjęte zasady, które warto stosować podczas pisania testów. Sprawiają, że testy są bardziej użyteczne w Twoim projekcie. Do każdej z tych zasad podam Ci konkretne techniki i wskazówki, aby je spełnić. Zasady mają akronim F.I.R.S.T. i kolejne litery oznaczają:

  • Fast
  • Isolated / Independent
  • Repeatable
  • Self-validating
  • Timely
Assert Object Pattern – wyraź w testach biznesowe znaczenie obiektu

Assert Object Pattern – wyraź w testach biznesowe znaczenie obiektu

Assert Object pattern to bardzo prosty wzorzec stosowany w kodzie testowym sprawiając, że są prostsze i bardziej czytelne. Koncentruje się na fazie sprawdzania obiektów ukrywając złożoność sprawdzenia.

Ideą wzorca Assert Object jest „owinięcie” testowanego obiektu w obiekt Assert i stworzenie metod sprawdzających. Dzięki temu możemy wyrażać biznesowe znaczenie.

Wzorzec Test Data Builder – podnieś czytelność kodu testowego. Biblioteka make-it-easy

Wzorzec Test Data Builder – podnieś czytelność kodu testowego. Biblioteka make-it-easy

Kod testowy składa się z trzech części: 1. Przygotowanie (given / arrange), 2. Wykonanie (when / act), 3. Sprawdzenie (then / assert)

Przygotowanie danych do wykonania testu wymaga stworzenia obiektów, wypełnienia konstruktorów, dostarczenia danych. Może być trudne w przypadku bardziej złożonych obiektów.

Oprócz stworzenia obiektów możliwe, że należy doprowadzić je do konkretnego stanu przechodząc przez operacje.

Kod w fazie given się powtarza pomiędzy testami i zaciemnia test.

Nie działa środowisko? 🤬 Stabilne testowanie integracyjne z infrastrukturą 🧘‍♂️ Projekt Testcontainers

Nie działa środowisko? 🤬 Stabilne testowanie integracyjne z infrastrukturą 🧘‍♂️ Projekt Testcontainers

Chyba każdy zna to uczucie. Chcemy coś przetestować, albo zbliża się release i … środowisko nie działa. Nasza aplikacja ma zależność – albo do bazy danych, albo do brokera wiadomości, albo do innej części infrastruktury. I co teraz? Jest jakaś metoda, aby z jednej strony wyizolować infrastrukturę, ale z drugiej nie mieć wszystkiego zamockowane, albo w implementacjach in-memory i jednak przetestować te interakcje?

W tym wpisie chciałbym polecić Twojej uwadze projekt Testcontainers. Podejdziemy do tematu z różnych perspektyw.

5 najczęstszych błędów, kiedy używasz Apache Kafka

5 najczęstszych błędów, kiedy używasz Apache Kafka

Integracja aplikacji ze sobą za pomocą Apache Kafka jest stosunkowo łatwa. W tym zadaniu wspomagają nas biblioteki albo całe frameworki (takie jak Spring). Ponieważ to zadanie jest znacznie ułatwione, może to uśpić czujność programistów. Chciałbym zwrócić Twoją uwagę na to, żebyś poświęcił chwilę na analizę wymagań niefunkcjonalnych w swojej aplikacji, a także zapoznał się z domyślnymi ustawieniami Apache Kafka i bibliotek integrujących.

Fail Fast 🔥 w Java

Fail Fast 🔥 w Java

Uwielbiam kod, który nie zaskakuje. Kiedy praca na modelu domenowym ułatwia rozwiązywanie problemu. Kiedy pojęcie w systemie jest spójne i nie czyhają na mnie dodatkowe pułapki związane z tym, że zaraz użyję istniejącego już fragmentu.

Właściwie w takim celu powstaje model dziedzinowy (domain model) – żeby za pomocą zdefiniowanych pojęć, które wyrażają: agregaty, parametry procesu lub jego wynik, pomogły mi ich użyć w przewidywalny sposób.

Dlatego wolę, żeby niewłaściwie użyty kod wywrócił się od razu, niż ukrył problem, którego skutki objawią się w innym, dalszym miejscu w procesie.

Takie podejście/technika nazywa się Fail fast.

Monitoring Mikrousług – diagnostyka problemów w środowisku rozproszonym

Monitoring Mikrousług – diagnostyka problemów w środowisku rozproszonym

Wyobraź sobie, że wystąpił problem w produkcyjnym systemie zbudowanym z sieci rozproszonych mikrousług. Błąd przekazuje zespół, który złożył żądanie do Twojego systemu i operacja zawiodła – obsługa trwała długo, a następnie został zwrócony błąd. Podają requestId oraz szczegóły żądania.

Czy byłbyś w stanie szybko odpowiedzieć, co konkretnie było przyczyną błędu?

W tym wpisie chciałbym poruszyć problematykę Observability (obserwowalności) systemów opartych o architekturę rozproszonych mikrousług. Opowiem o:

  • Log Aggregation, zbieranie logów w środowisku rozproszonym
  • Distributed Tracing, czyli śledzenie konkretnego żądania
  • Monitoring ogólnej kondycji systemu
    • Perspektywa ogólna serwisu
    • Perspektywa szczegółowa instancji
Dlaczego gettery i settery są niebezpieczne? Anemic Domain Model vs Rich Domain Model

Dlaczego gettery i settery są niebezpieczne? Anemic Domain Model vs Rich Domain Model

Istnieje powód, dla którego korzystamy ze zmiennych prywatnych w naszych klasach. Nie chcemy ich udostępniać na zewnątrz i nie chcemy, aby ktoś na nich polegał. Uczono nas, że publiczne zmienne w klasie to zło. Dlaczego więc tak wielu programistów „automatycznie” dodaje gettery i settery do swoich modeli, sprawiając, że prywatne zmienne są widziane na zewnątrz? Nie raz pewnie widziałeś w kodzie adnotacje Lomboka @Setter, @Getter czy @Data nad większością klas. W dzisiejszym wpisie przyjrzymy się bardziej szczegółowo często pomijanej kwestii akcesorów, mutatorów, a następnie przejdziemy do omówienia Anemic Domain Model oraz Rich Domain Model.