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

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

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.

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.