Oczywiście jest to łatwe w teorii, nieco trudniejsze w praktyce. Jak więc poradzić sobie z wyzwaniem pt. po wywołaniu HTTP powinien być komunikat w Kafce? Na przykład przy pomocy biblioteki testcontainers: https://www.testcontainers.org/, która pozwala uruchomić wasz serwis oraz jego zależności w postaci kontenerów. Naturalnie symulowanie całego klastra np. kubernetes mija się z celem, natomiast z powodzeniem można dorzucić przynajmniej tę część infrastruktury, która zapewnia komunikację.
Testcontainers poza podstawową funkcjonalnością pozwalającą na uruchomienie dowolnego kontenera z kodu Javy, dostarcza również moduły dla PostgreSQL, MySQL, Cassandra czy też ElasticSearch - lista kontenerów do przejrzenia: https://mvnrepository.com/artifact/org.testcontainers. Z ciekawszych rzeczy - można uruchomić z testem również selenium, które działa w kontenerze, bez konieczności aranżowania wszystkich zależności systemowych potrzebnych do uruchomienia przeglądarki. Brzmi świetnie, nieprawdaż?
#java #docker
@splatch część problemów/wyzwań w testowaniu mikroserwisów jesteś w stanie też opędzić WireMock'iem (rest call). Spoko się integruje ze Spring Boot Test (zarówno ze Spock jak i Junit5, z Junit4 też powinno śmigać) oraz wspomnianym przez Ciebie Testcontainers. Trochę setupu i masz postawione w testach całe "środowisko" oraz wszystko co wymagane do ich przeprowadzenia
@damw zgadzam się, wiremock może odhaczyć sporo, zwłaszcza integracji z zewnętrznymi usługami po http, ale nie da rady ogarnąć kolejek. Pytanie też ile pracy i niespójności jest z tym żeby utrzymać np. kod pracujący z postgresql/mysql (nie daj boże Oracle! :D) na produkcji i h2 w testach. Są sytuacje w których rozjeżdżają się detale między liquibase/hibernate chociażby na obsłudze mapowania uuid i tym podobnych.
Wiem, że jest gdzieś balans pomiędzy tym ile wrzuca się osadzonych usług (np. kolejki, bazy in memory), a jakością kodu testów, która z biegiem czasu i przyrostem przypadków testowych zazwyczaj się degraduje. Co przywodzi nas do kolejnego punktu, czyli testów z BDD cucumberem, który pozwala opisywać przypadki testowe w przejrzystej formie. Ale to temat na oddzielny wpis, który powinien być okraszony przykładem!
w jaki sposób testy integracyjne mają "ingerować w wewnętrzne komponenty systemu"? przecież to się wyklucza
@Kazix Chodzi głównie o przygotowanie testu w trakcie którego zamieniając komponent na potrzeby testu z docelowego (np. baza danych, kolejka JMS lub topic Kafki na implementację in-memory) pośrednio ingeruje się w zachowanie systemu. Twój test wciąż jest integracyjny, ponieważ wchodzić w interakcję na wyższych warstwach, ale do weryfikacji wyników wymaga wymiany warstw niższych.
ale nie da rady ogarnąć kolejek
@splatch dlatego napisałem przy wiremocku rest call. Te 2 narzędzia się uzupełniają - testcontainers do stawiania faktycznej bazy/kolejki itd, wiremock do "mockowania" innych mikroserwisów z których korzysta testowany komponent.
@splatch testcontainers zjada hibernate na śniadanie i wyplówa pestki. Jest sztos.
Zaloguj się aby komentować