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.
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.
Korzystając z Hibernate czy też Java Persistence API dla konfiguracji mapowania danych i operacji korzystasz z mapowania dla encji, operacji i relacji. Ale Hibernate dostarcza dodatkowych anotacji, z których chciałbym Ci przedstawić kilka wybranych.
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.
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:
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.
Tworząc systemy, które wymieniają dane z bazą danych, chcesz, aby komunikacja była niezawodna.
Możesz wykonywać operacje, które mogą być krótkie, ale za to częste, a może będziesz wykonywał takie, które są bardzo długie.
Operacje są wykonywane w ramach nawiązanego wcześniej połączenia do bazy.
Użytkowników systemu przeważnie jest wielu, a ich sesje powinny być niezależne.
W pewnym momencie może się zdarzyć, że użytkownik nie będzie mógł wykonać jakiejś operacji,
ponieważ baza danych odrzuci kolejne połączenie ze względu na jakiś limit.
Ale przez odpowiednią konfigurację możesz zoptymalizować szybkość działania Systemu w zakresie dostępu do nawiązanego
połączenia do bazy danych.
Konsument Kafki jest używany do optymalnego odczytywania wiadomości z partycji topika, który subskrybuje. Główną rolą konsumenta jest wziąć połączenie do klastra Kafki oraz ustawienia konsumenta, aby połączyć się z brokerem i zacząć odczytywać wiadomości.
W Hibernate wiele operacji wykonywanych jest „auto magicznie”. Nie znając specyfiki, możesz doprowadzić do spadku wydajności.
Jeśli poznasz i zrozumiesz zasady działania, będziesz w stanie poprawić wydajność operacji związanych z komunikacją z bazą danych.
Wiedząc jak włączyć monitorowanie, zweryfikujesz czy zapytania wysyłane do bazy danych są tymi, których się spodziewałeś.
Jak działa Lazy-Loading? Jak obsłużyć operacje masowe? Czym jest problem N+1?
Jak stworzyć piekielnie szybką albo maksymalnie bezpieczną wersję producenta oraz konsumenta.
Twórz szybko działające aplikacje z wydajną i zoptymalizowaną obsługą bazy danych
Pobierz za darmo książkę 100 stron o technikach testowania w Java
