Być może uczestniczyłeś w dyskusjach – co mockować, a czego nie. Albo czym jest unit w unit testach?
Żeby coś porządnie przetestować to mockować, czy nie? Jakie są problemy z mockowaniem? Kiedy mockować, a kiedy nie? Co daje nam piramida testów w kontekście mockowania?
W tym wpisie podejdę do tematu z wielu stron.
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.
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.
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.
SDKMAN to narzędzie oryginalnie stworzone dla *nix-owych systemów operacyjnych w prosty sposób pozwala na pobieranie i przełączanie się pomiędzy różnymi SDK na maszynie.
Wspiera instalację wielu środowisk SDK, np. dla Java, Groovy, Scala, Kotlin, Maven, Micronaut. Poprzednio znane jako GVM (Groovy enVironment Manager).
W tym wpisie skupie się na instalacji narzędzia na Windows i po krótce przejdę przez najważniejsze funkcje.
