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.
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.
