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
@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!