![\"Testcontainers](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/9-2.png\")
<\/a>Docker dla testera manualnego<\/strong><\/h2>\n\n\n\nJe\u015bli mia\u0142e\u015b do czynienia z bazami danych, to prawdopodobnie przypominasz sobie w\u0142asny wysi\u0142ek w\u0142o\u017cony w przygotowanie \u201eod zera\u201d \u015brodowisko pracy z DB. Nawet je\u015bli to tylko lokalne \u015brodowisko, musisz mie\u0107 drivera i klienta DB oraz w\u0142a\u015bciwie wszystko skonfigurowa\u0107, tworz\u0105c poprawny connection string<\/em>. Szczeg\u00f3lnie wa\u017cne jest to w przypadku baz danych Oracle.<\/p>\n\n\n\nZnacznie sprawniej mo\u017cna to zrobi\u0107 przy u\u017cyciu Dockera. Centralne repozytorium obraz\u00f3w Dockera<\/a> zawiera ci\u0105gle rozwijan\u0105 baz\u0119 obraz\u00f3w, a w\u015br\u00f3d nich obrazy bazy danych Oracle. Producent prezentuje swoje oficjalne obrazy, ale te\u017c inni developerzy udost\u0119pniaj\u0105 w\u0142asne wersje. S\u0142owem \u2013 mamy wszystkie wersje niemal dowolnego narz\u0119dzia w jednym miejscu<\/strong>.<\/p>\n\n\n\nWybieram wersj\u0119 Oracle np. 9, reprezentowan\u0105 dockerowym tagiem i mog\u0119 zastosowa\u0107 komend\u0119 \u015bci\u0105gaj\u0105c\u0105 obraz na dysk lokalny:<\/p>\n\n\n\n
![\"Komenda](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/1-3.png\")
<\/a>Ryc. 2 Komenda \u015bci\u0105gaj\u0105ca obraz<\/figcaption><\/figure><\/div>\n\n\n\nKorzy\u015b\u0107 jest znaczna, bo to, co pojawi si\u0119 na naszym dysku w postaci obrazu [image<\/em>] dockerowego, zawiera ju\u017c wszystko, czego potrzebujemy, aby korzysta\u0107 z bazy danych. Kolejna komenda [docker run<\/em>], kt\u00f3ra uruchomi kontener, sprawi, \u017ce baza danych b\u0119dzie ju\u017c dost\u0119pna do pracy. <\/p>\n\n\n\n![\"Komenda](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/2-3.png\")
<\/a>Ryc. 3 Komenda uruchamiaj\u0105ca kontener<\/a><\/figcaption><\/figure><\/div>\n\n\n\nW opisie danego obrazu autor najcz\u0119\u015bciej podaje gotowe komendy w r\u00f3\u017cnych wersjach. Wystarczy tylko uruchomi\u0107 je lokalnie w konsoli Windows.<\/p>\n\n\n\n
Zalety i wady rozwi\u0105zania<\/strong><\/h3>\n\n\n\nNie twierdz\u0119, \u017ce obs\u0142uga Dockera jest trywialna, ale stawiam tez\u0119, \u017ce jak kto\u015b raz spr\u00f3buje, to ju\u017c nie wr\u00f3ci<\/strong> do wymagaj\u0105cych instalacji i \u017cmudnej konfiguracji wersji desktopowych.<\/p>\n\n\n\nIstnieje te\u017c znaczna oszcz\u0119dno\u015b\u0107 przestrzeni dyskowej. Instalacja natywnego narz\u0119dzia prawie zawsze zajmuje wielokrotnie wi\u0119cej miejsca na dysku ni\u017c obraz dockerowy.<\/p>\n\n\n\n
Do minus\u00f3w i niedogodno\u015bci<\/strong> nale\u017cy jednokrotna instalacja samego Dockera. Jest to narz\u0119dzie konsolowe, ale w systemie Windows mo\u017cna korzysta\u0107 w Docker Desktop, kt\u00f3re umo\u017cliwia przejrzyste zarz\u0105dzanie obrazami i kontenerami Dockera.<\/p>\n\n\n\n![\"Docker](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/3-3.png\")
<\/a>Ryc. 4 Docker desktop<\/a><\/figcaption><\/figure><\/div>\n\n\n\nTrzeba te\u017c przyzna\u0107, \u017ce musimy opanowa\u0107 konsolowe komendy, kt\u00f3re pozwol\u0105 swobodnie porusza\u0107 si\u0119 w Dockerze. Jest to jednak g\u0142\u00f3wnie wysi\u0142ek czasowy, bo z pe\u0142nym przekonaniem twierdz\u0119, \u017ce darmowe \u017ar\u00f3d\u0142a wiedzy na ten temat<\/a> w sieci s\u0105 wystarczaj\u0105ce i nie ma potrzeby inwestowa\u0107 w p\u0142atne szkolenia<\/strong> w przypadku testera manualnego.<\/p>\n\n\n\nDocker dla testera automatyzuj\u0105cego i programisty<\/strong><\/h2>\n\n\n\nProgrami\u015bci ju\u017c docenili Dockera i czerpi\u0105 z niego pe\u0142nymi gar\u015bciami. Kontener z dowoln\u0105 aplikacj\u0105 uruchamiamy b\u0142yskawicznie (kwestia milisekund), korzystamy z niej i zamykamy r\u00f3wnie szybko. Kiedy zapis stanu aplikacji nie ma dla nas znaczenia, to sprawa jest zupe\u0142nie bezproblemowa. Nie ma r\u00f3wnie\u017c k\u0142opotu, gdy potrzebna jest komunikacja mi\u0119dzy dyskiem lokalnym a kontenerem np. poprzez wys\u0142anie pliku do kontenera lub odebranie pliku z kontenera na dysk.<\/p>\n\n\n\n
Mo\u017cliwe jest tak\u017ce uruchomienie wielu kontener\u00f3w jednocze\u015bnie i po\u0142\u0105czenie ich w jedn\u0105 sie\u0107 \u2013 Network.<\/em><\/p>\n\n\n\nTestcontainers<\/strong><\/h2>\n\n\n\nPojawi\u0142o si\u0119 jednak wyzwanie dla testowania aplikacji, kt\u00f3re korzystaj\u0105 z kontener\u00f3w, zw\u0142aszcza tych opartych na architekturze mikroserwisowej. Testy integracyjne to faza, podczas kt\u00f3rej chcemy zbada\u0107 wsp\u00f3lne dzia\u0142anie r\u00f3\u017cnych komponent\u00f3w systemu np. API Restowe i baza danych czy te\u017c mikroserwis produkuj\u0105cy wiadomo\u015bci na Kafk\u0119 i konsumuj\u0105cy te wiadomo\u015bci wraz z brokerem kafkowym.<\/p>\n\n\n\n
Przygotowuj\u0105c automatyczne testy integracyjne dla takiej architektury, niezb\u0119dne jest wykorzystanie kontenera bazy danych<\/strong> np. PostgreSQL czy kolejki np. Kafka. Kontener ten musi by\u0107 uruchamiany w kodzie.<\/p>\n\n\n\nTutaj w\u0142a\u015bnie na scen\u0119 wchodzi Testcontainers. Jest to biblioteka, kt\u00f3ra dostarcza API do obs\u0142ugi kontener\u00f3w dockerowych w kodzie<\/strong>. Narz\u0119dzie obs\u0142uguje nast\u0119puj\u0105ce j\u0119zyki programowania:<\/p>\n\n\n\n- Java,<\/li>
- Go,<\/li>
- .NET,<\/li>
- Python,<\/li>
- Node.js,<\/li>
- Rust.<\/li><\/ul>\n\n\n\n
![\"J\u0119zyki](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/4a.png\")
<\/a>Ryc. 5 J\u0119zyki programowania obs\u0142ugiwane przez Testcontainers<\/a><\/figcaption><\/figure><\/div>\n\n\n\nBiblioteka dostarcza automatyczne zarz\u0105dzanie uruchamianiem i zamykanie kontener\u00f3w zaraz po zako\u0144czonym te\u015bcie. To niezwykle \u201eestetyczne\u201d podej\u015bcie. \u015arodowisko testowanej aplikacji jest budowane stosunkowo szybko (ok. 2-3 dodatkowe sekundy) automatycznie zaraz przed testem. Nast\u0119pnie wykonywana jest logika naszych scenariuszy i zwracany rezultat, a na koniec kontener znika bezpowrotnie.<\/p>\n\n\n\n
Ta \u201eefemeryczno\u015b\u0107\u201d dla testera automatyzuj\u0105cego jest niezwykle atrakcyjna. Testcontainers dostarcza mechanizm przygotowania \u201ew locie\u201d danych testowych. Znika r\u00f3wnie\u017c potrzeba czyszczenia stanu po te\u015bcie w trosce o to, by artefakty i pozostawione dane nie wp\u0142ywa\u0142y przypadkiem na nast\u0119pne egzekucje tego samego testu. Tutaj ka\u017cde uruchomienie testu posiada w\u0142asn\u0105, \u201e\u015bwie\u017c\u0105\u201d instancj\u0119 komponentu, kt\u00f3ra ginie po te\u015bcie wraz z ca\u0142\u0105 swoj\u0105 zawarto\u015bci\u0105.<\/p>\n\n\n\n
Testcontainers\/ryuk<\/strong><\/h3>\n\n\n\nObiekt, kt\u00f3ry zarz\u0105dza zamykaniem wybranych kontener\u00f3w to \u201etestcontainers\/ryuk<\/strong>\u201d. Uruchamia si\u0119 zawsze, mimo i\u017c wprost nie deklarujemy tego w kodzie. To kontener uprzywilejowany<\/strong>, kt\u00f3ry odpowiada za prawid\u0142owe i automatyczne zamykanie kontener\u00f3w [automatic cleanup].<\/em><\/p>\n\n\n\nMechanizm ten ma du\u017ce znaczenie zw\u0142aszcza, kiedy ko\u0144czymy egzekucj\u0119 test\u00f3w w niestandardowy spos\u00f3b np.:<\/p>\n\n\n\n
- pojawia si\u0119 exception w trakcie wykonania scenariusza,<\/li>
- nie uda\u0142o si\u0119 uruchomi\u0107 pe\u0142nego \u015brodowiska do test\u00f3w, bo zabrak\u0142o jednego kontenera,<\/li>
- w czasie debugowania zamykamy test z poziomu IDE.<\/li><\/ul>\n\n\n\n
Wszystkie te i podobne sytuacje powoduj\u0105 wymuszenie zamkni\u0119cia uruchomionych kontener\u00f3w, aby nie pozostawi\u0107 w pami\u0119ci \u201emartwych kontener\u00f3w\u201d. <\/em>Dokumentacja biblioteki pozwala wprawdzie na w\u0142asn\u0105 konfiguracj\u0119 ryuk,<\/strong> a nawet wy\u0142\u0105czenie go, ale jest to niewskazane.<\/p>\n\n\n\nTestcontainers dla j\u0119zyka JAVA \u2013 demo<\/strong><\/h2>\n\n\n\nPrzedstawi\u0119 praktyczny przyk\u0142ad u\u017cycia Testcontainers w kodzie Java. Chc\u0119 wykorzysta\u0107 baz\u0119 danych PostgreSQL jako komponent podczas testowania kontrolera [Controller<\/em>] w prostym microservice. Wybra\u0142em framework Micronaut, ale r\u00f3wnie dobrze zadzia\u0142a to z tradycyjnym Spring Boot.<\/p>\n\n\n\nSerwis to klasyczny CRUD \u2013 pozwala na odczyt, zapis, edycj\u0119 i usuwanie encji Actor do bazy danych. Posiada podzia\u0142 na warstwy:<\/p>\n\n\n\n
- Controller,<\/li>
- Service,<\/li>
- Repository.<\/li><\/ul>\n\n\n\n
W Micronaucie taka klasa modelowa b\u0119dzie wygl\u0105da\u0142a nast\u0119puj\u0105co:<\/p>\n\n\n
\npackage com.example;\n\nimport io.micronaut.core.annotation.Nullable;\nimport io.micronaut.data.annotation.GeneratedValue;\nimport io.micronaut.data.annotation.MappedEntity;\nimport io.swagger.v3.oas.annotations.media.Schema;\nimport javax.persistence.Entity;\nimport javax.persistence.GenerationType;\nimport javax.persistence.Id;\nimport javax.validation.constraints.NotBlank;\nimport javax.validation.constraints.Size;\n\n@Schema(description="Actor business model")\n@Entity\npublic class Actor\n {\n @GeneratedValue @Id\n @Nullable\n private Long id;\n @NotBlank @Size(max = 20)\n private String firstName;\n @NotBlank @Size(max = 20)\n private String lastName;\n @NotBlank\n private Long rating;\n\n\/\/getters and setters\n}\n[src\/main\/java\/model\/Actor] \n<\/pre><\/div>\n\n\nZdefiniowa\u0142em DataSource w pliku konfiguracyjnym application.yml<\/strong> dla Postgresa, kt\u00f3ry wygl\u0105da nast\u0119puj\u0105co:<\/p>\n\n\n\ndatasources:\n default:\n url: jdbc:postgresql:\/\/localhost:5432\/actor\n driverClassName: org.postgresql.Driver\n username: postgres\n password: postgres\n schema-generate: NONE\n dialect: POSTGRES\n schema: public\n<\/pre><\/div>\n\n\nKiedy baza danych z odpowiednim schematem jest uruchomiona, wszystko dzia\u0142a bez zarzutu. Mog\u0119 wykona\u0107 moje testy API napisane np. w RestAssured. Je\u015bli jednak wy\u0142\u0105cz\u0119 baz\u0119 danych, \u017caden test nie da wiarygodnych rezultat\u00f3w. Testcontainer pozwoli mi na \u201ew\u0142\u0105czenie\u201d brakuj\u0105cego komponentu tylko na czas wykonania moich test\u00f3w.<\/p>\n\n\n\n
Pierwszym krokiem jest pobranie zale\u017cno\u015bci do projektu:<\/p>\n\n\n\n
Maven<\/strong>:<\/p>\n\n\n\n<dependency>\n <groupId>org.junit.jupiter<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>5.8.1<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>testcontainers<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<\/pre><\/div>\n\n\nGradle<\/strong>:<\/p>\n\n\n\ntestImplementation "org.junit.jupiter:junit-jupiter:5.8.1"\ntestImplementation "org.testcontainers:testcontainers:1.17.6"\ntestImplementation "org.testcontainers:junit-jupiter:1.17.6"\n<\/pre><\/div>\n\n\nNast\u0119pnie definiuj\u0119 DataSource na poziomie test\u00f3w. W Micronaut odpowiedzialny jest za to plik konfiguracyjny application-test.yml:<\/strong><\/p>\n\n\n\ndatasources:\ndefault:\nurl: jdbc:tc:postgresql:latest:\/\/\/postgres?TC_INITSCRIPT=file:src\/test\/resources\/init-actor-testdata.sql?TC_DAEMON=true\n \tdriverClassName: org.testcontainers.jdbc.ContainerDatabaseDriver\n \tminimum-idle: 5\n<\/pre><\/div>\n\n\nZwr\u00f3\u0107cie uwag\u0119, \u017ce parametr url<\/em> jest oznaczony przez tc<\/strong> \u2013 [jdbc:tc] \u2013 co wskazuje, \u017ce jego obs\u0142ug\u0105 zajmie si\u0119 Testcontainers. Dodatkowo, driverClassName <\/em>r\u00f3wnie\u017c zawiera wskazanie na pakiet org.testcontainers.<\/p>\n\n\n\nTeraz ju\u017c mo\u017cemy w kodzie klasy testowej zaznaczy\u0107, \u017ce b\u0119dziemy wykorzystywali kontenery Dockera poprzez adnotacj\u0119 @Testcontainers<\/strong> przed klas\u0105.<\/p>\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n}\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\noraz adnotacj\u0105 @Container<\/strong> przed polem, kt\u00f3ry definiuje typ I wersj\u0119 kontenera:<\/p>\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nPozosta\u0142e adnotacje to:<\/p>\n\n\n\n
- @MicronautTest(environments = „test”) \u2013 micronautowe oznaczenie, \u017ce b\u0119dziemy korzysali z testowego kontekstu Micronauta.<\/li>
- @Slf4j \u2013 adnotacja Lombok uruchamiaj\u0105ca logger w klasie.<\/li><\/ul>\n\n\n\n
Klasa PostgreSQLContainer <\/em>zapewnia nam prawid\u0142ow\u0105 obs\u0142ug\u0119 tego szczeg\u00f3\u0142owego kontenera PostgreSQL. Istnieje ponadto generyczna klasa GenericContainer<\/em>, kt\u00f3r\u0105 zawsze mo\u017cemy wykorzysta\u0107 do przechowania obiektu dowolnego kontenera:<\/p>\n\n\n\n@Container\n private static final GenericContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n<\/pre><\/div>\n\n\nBiblioteka Testcontainers wymaga, aby\u015bmy dodali absolutnie minimaln\u0105 i niezb\u0119dn\u0105 konfiguracj\u0119 naszego kontenera. Musimy przecie\u017c wybra\u0107, jaki image postgres potrzebujemy, zdefiniowa\u0107 nazw\u0119 schematu, username i password.<\/p>\n\n\n\n
Osobi\u015bcie preferuj\u0119 umieszczenie takiej konfiguracji nie w klasie testowej, ale w osobnej klasie odpowiedzialnej za kontenery postgresa. Ma to sens, poniewa\u017c postgres to nie jedyny komponent, jakiego potencjalnie mo\u017cemy potrzebowa\u0107. Gdy pojawi si\u0119 Kafka, Redis czy MongoDB, to bezpiecznie odseparujemy wszystkie te konfiguracje.<\/strong><\/p>\n\n\n\nKod takiej klasy mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n\n\n
\npackage com.example.containers;\n\nimport org.testcontainers.containers.PostgreSQLContainer;\nimport org.testcontainers.utility.DockerImageName;\n\npublic class PostgresContainer extends PostgreSQLContainer<PostgresContainer> {\n private static final String MYPOSTGRESIMAGE = "postgres:latest" ;\n private static final String MYTESTDATABASENAME = "actor";\n private static final String USERNAME = "postgres";\n private static final String PASSWD = "postgres";\n private static final Integer DB_PORT = 5432;\n\n private PostgresContainer() {\n super(DockerImageName.parse(MYPOSTGRESIMAGE));\n }\n\n public static PostgreSQLContainer<?> getContainerPostgres() {\n return new PostgreSQLContainer<>(DockerImageName.parse(MYPOSTGRESIMAGE))\n .withDatabaseName(MYTESTDATABASENAME)\n .withExposedPorts(DB_PORT)\n .withUsername(USERNAME)\n .withPassword(PASSWD);\n }\n}\n[src\/test\/containers\/PostgresContainer]\n<\/pre><\/div>\n\n\nNajistotniejsza jest tu statyczna metoda \u2013 getContainerPostgres<\/em>(). To tutaj za pomoc\u0105 wielu metod rozpoczynaj\u0105cych si\u0119 od \u201ewith\u201d ustawiamy stan naszego kontenera oraz sposoby \u0142\u0105czenia si\u0119 z nim.<\/p>\n\n\n\nTryb \u0142a\u0144cuchowego wywo\u0142ania tych metod dodaje ogromnej wygody:<\/p>\n\n\n\n![\"tryb](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/4-2.png\")
<\/figure>\n\n\n\nTeraz pozostaje ju\u017c tylko przekazanie do testowego DataSource szczeg\u00f3\u0142\u00f3w po\u0142\u0105czenia z kontenerow\u0105 baz\u0105 danych. Wraz z micronautow\u0105 adnotacj\u0105 @MockBean jest to bardzo proste i mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co w klasie testowej:<\/p>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n private DataSource postgresDataSource;\n\n private JdbcTemplate jdbcTemplate;\n\n @Inject\n public JdbcTemplateExampleTest(DataSource postgresDataSource) {\n this.postgresDataSource = postgresDataSource;\n }\n\n @MockBean(DBConnector.class)\n DBConnector postgresConnection() {\n PostgresTestContainer dbConnection = new PostgresTestContainer();\n dbConnection.setUrl(postgres.getJdbcUrl());\n dbConnection.setUsername(postgres.getUsername());\n dbConnection.setPasswd(postgres.getPassword());\n return dbConnection;\n }\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nWidoczny w klasie bean JdbcTemplate pos\u0142u\u017cy\u0142 mi tylko jako connector do bazy danych. To dzi\u0119ki niemu b\u0119dziemy wiedzieli, \u017ce baza danych rzeczywi\u015bcie pojawi si\u0119, kiedy jej potrzebujemy, bo b\u0119dziemy mogli wykona\u0107 nasze zapytania i odebra\u0107 rezultaty.<\/p>\n\n\n\n
Kiedy wszystko jest przygotowane mog\u0119 zaimplementowa\u0107 dwa proste testy:<\/p>\n\n\n\n
- Test 1 \u2013 shouldGetAllActorsFromDBBasedOnTestContainers() \u2013 pobranie wszystkich aktor\u00f3w z bazy \u2013 \u201eSELECT * FROM actor\u201d;<\/li>
- Test 2 \u2013 shouldGetSingleActorFromDBBasedOnTestContainers() \u2013 pobranie jednego aktora z bazy \u2013 \u201eSELECT firstname FROM actor WHERE id=1\u201d;<\/li><\/ul>\n\n\n
\n@Test\n void shouldGetAllActorsFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getLoadedRecords();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults.get(0).get("firstname")).isEqualTo("Brad");\n assertThat(dbResults.get(1).get("firstname")).isEqualTo("Angelina");\n assertThat(dbResults.get(2).get("firstname")).isEqualTo("Salma");\n }\n\n @Test\n void shouldGetSingleActorFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getSingleRecord();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults).isEqualTo("Brad");\n }\n\n private boolean isRecordLoaded() {\n return jdbcTemplate.queryForList("Select * from actor").size() > 1;\n }\n\n private List<Map<String, Object>> getLoadedRecords() {\n return jdbcTemplate.queryForList("Select * from actor");\n }\n\n private String getSingleRecord() {\n return jdbcTemplate.queryForObject("Select firstname from actor where id=1", String.class);\n }\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nWyniki<\/strong><\/h3>\n\n\n\nOto rezultaty klasy testowej uruchomionej lokalnie w IDE. Zwr\u00f3\u0107 uwag\u0119, jak logi w konsoli wyra\u017anie wskazuj\u0105, \u017ce:<\/p>\n\n\n\n
- uruchomi\u0142 si\u0119 Docker,<\/li>
- uruchomi\u0142 si\u0119 uprzywilejowany kontener Testcontainers\/ryuk,<\/li>
- uruchomi\u0142 si\u0119 kontener PostgreSQL<\/li><\/ul>\n\n\n\n
I co najwa\u017cniejsze \u2013 czas wykonania obu test\u00f3w to zaledwie 0,5 sek!<\/strong><\/p>\n\n\n\n![\"Rezultaty](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/5-2-1024x383.png\")
Ryc. 6 Rezultaty klasy testowej uruchomionej w lokalnej IDE<\/figcaption><\/figure>\n\n\n\nDodatkowo, na potwierdzenie dodaj\u0119 jeszcze widok z Docker Desktop w czasie wykonania test\u00f3w. Wida\u0107 wyra\u017anie, \u017ce potrzebne kontenery s\u0105 w statusie running:<\/p>\n\n\n\n
![\"Widok](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/6-2-1024x268.png\")
<\/a>Ryc. 7 Widok z Docker Desktop w czasie wykonania test\u00f3w<\/figcaption><\/figure><\/div>\n\n\n\nMo\u017cna zauwa\u017cy\u0107, jak Testcontainer pozwoli\u0142 mi minimalnym wysi\u0142kiem implementowa\u0107 dowolne testy integracyjne. Niezb\u0119dne komponenty \u201ewstaj\u0105\u201d w postaci kontener\u00f3w dockerowych, a po wykonanym te\u015bcie komponenty te s\u0105 usuwane.<\/p>\n\n\n\n
Jest jeszcze jedno zagadnienie, kt\u00f3re uznaj\u0119 jako niezwykle przydatne w Testcontainers. S\u0105 to opcje (flagi), kt\u00f3re definiuj\u0119 w pliku konfiguracyjnym<\/strong> application-test.yml:<\/em><\/p>\n\n\n\n- TC_INITSCRIPT<\/li>
- TC_DAEMON<\/li><\/ul>\n\n\n\n
![\"Flagi](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/7-2-1024x139.png\")
<\/a>Ryc. 8 Flagi definiowane w pliku konfiguracyjnym application-test.yml<\/figcaption><\/figure><\/div>\n\n\n\nTC_INITSCRIPT<\/strong><\/h3>\n\n\n\nZrozumia\u0142e jest, \u017ce kiedy korzystamy z bazy danych, chcieliby\u015bmy, \u017ceby ju\u017c by\u0142 tam schemat, tabele i jakie\u015b dane testowe niezb\u0119dne do wykonania testu. Dzi\u0119ki opcji TC_INITSCRIPT, mo\u017cemy zdefiniowa\u0107 skrypt SQL, kt\u00f3ry wykona si\u0119 zaraz po uruchomieniu kontenera DB, ale przed wykonaniem pierwszej linijki kodu.<\/p>\n\n\n\n
W moim demo wykorzysta\u0142em nast\u0119puj\u0105cy skrypt, dzi\u0119ki czemu nie musia\u0142em w kodzie testu obs\u0142ugiwa\u0107 zawarto\u015bci mojej bazy PostgreSQL:<\/p>\n\n\n\n
![\"Skrypt](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/8-2-1024x396.png\")
<\/a>Ryc. 9 Skrypt src\/test\/resources\/init-actor-testdata.sql<\/figcaption><\/figure><\/div>\n\n\n\nTC_DAEMON<\/strong><\/h3>\n\n\n\nW domy\u015blnym ustawieniu kontener bazy danych jest zatrzymywany po zamkni\u0119ciu ostatniego po\u0142\u0105czenia. Bywaj\u0105 jednak sytuacje, w kt\u00f3rych b\u0119dziemy chcieli, aby kontener dzia\u0142a\u0142 do momentu jego wyra\u017anego zatrzymania lub wy\u0142\u0105czenia maszyny JVM. Aby to zrobi\u0107, dodaj parametr TC_DAEMON do adresu URL jak w grafice wy\u017cej.<\/p>\n\n\n\n
Podsumowanie<\/strong><\/h2>\n\n\n\nTestcontainers to biblioteka do obs\u0142ugi kontener\u00f3w dockerowych w kodzie. Doskonale sprawdza si\u0119<\/strong> podczas tworzenia efemerycznych komponent\u00f3w w zautomatyzowanych testach integracyjnych. Pozwala te\u017c na za\u0142adowanie skrypt\u00f3w SQL w taki spos\u00f3b, \u017ce kontenerowa baza danych jest ju\u017c wyposa\u017cona w schemat i dane niezb\u0119dne do test\u00f3w.<\/p>\n\n\n\nPodczas pracy w Testcontainers zauwa\u017cy\u0142em dwie niedogodno\u015bci<\/strong>:<\/p>\n\n\n\n- trzeba mie\u0107 do\u015bwiadczenie w pracy z zewn\u0119trznymi bibliotekami Java. Samodzielna implementacja nie jest trywialna, jak nietrywialny jest sam Docker. Pr\u00f3g intelektualnego wej\u015bcia jest zatem zauwa\u017calny, ale widz\u0119 wyra\u017anie wysi\u0142ek tw\u00f3rc\u00f3w tej biblioteki, \u017ceby mo\u017cliwie upro\u015bci\u0107 developerom t\u0119 prac\u0119,<\/li>
- po ca\u0142odziennej pracy w Testcontainers i wielokrotnym uruchamianiu test\u00f3w integracyjnych zauwa\u017cam, \u017ce Docker, zw\u0142aszcza Docker Desktop w Windows OS, potrafi konsumowa\u0107 du\u017c\u0105 ilo\u015b\u0107 zasob\u00f3w komputera (RAM, procesor). Niejednokrotnie kontenery nie \u201ewstaj\u0105\u201d, a test ko\u0144czy si\u0119 b\u0142\u0119dem \u201eInitialization error\u201d. Mo\u017cemy wtedy skonfigurowa\u0107 w pliku .wslconfig<\/em> zakres dedykowanych zasob\u00f3w dla Dockera. Kiedy b\u0142\u0105d inicjalizacji kontener\u00f3w si\u0119 powtarza, najskuteczniejszym sposobem jest zwyk\u0142y restart komputera.<\/li><\/ul>\n\n\n\n
***
Je\u017celi interesuje Ci\u0119 temat Dockera, zach\u0119camy do przeczytania serii artyku\u0142\u00f3w przygotowanych przez naszego eksperta:<\/p>\n\n\n\n
- Docker dla programist\u00f3w: co to jest?<\/a><\/li>
- Docker dla programist\u00f3w \u2013 budowa pierwszego \u015brodowiska. Cz\u0119\u015b\u0107 I<\/a><\/li>
- Docker dla programist\u00f3w \u2013 budowa \u015brodowiska rozwojowego. Cz\u0119\u015b\u0107 II<\/a><\/li>
- Docker dla programist\u00f3w \u2013 dystrybucja aplikacji <\/a><\/li><\/ul>\n\n\n
Znacznie sprawniej mo\u017cna to zrobi\u0107 przy u\u017cyciu Dockera. Centralne repozytorium obraz\u00f3w Dockera<\/a> zawiera ci\u0105gle rozwijan\u0105 baz\u0119 obraz\u00f3w, a w\u015br\u00f3d nich obrazy bazy danych Oracle. Producent prezentuje swoje oficjalne obrazy, ale te\u017c inni developerzy udost\u0119pniaj\u0105 w\u0142asne wersje. S\u0142owem \u2013 mamy wszystkie wersje niemal dowolnego narz\u0119dzia w jednym miejscu<\/strong>.<\/p>\n\n\n\n Wybieram wersj\u0119 Oracle np. 9, reprezentowan\u0105 dockerowym tagiem i mog\u0119 zastosowa\u0107 komend\u0119 \u015bci\u0105gaj\u0105c\u0105 obraz na dysk lokalny:<\/p>\n\n\n\n Korzy\u015b\u0107 jest znaczna, bo to, co pojawi si\u0119 na naszym dysku w postaci obrazu [image<\/em>] dockerowego, zawiera ju\u017c wszystko, czego potrzebujemy, aby korzysta\u0107 z bazy danych. Kolejna komenda [docker run<\/em>], kt\u00f3ra uruchomi kontener, sprawi, \u017ce baza danych b\u0119dzie ju\u017c dost\u0119pna do pracy. <\/p>\n\n\n\n W opisie danego obrazu autor najcz\u0119\u015bciej podaje gotowe komendy w r\u00f3\u017cnych wersjach. Wystarczy tylko uruchomi\u0107 je lokalnie w konsoli Windows.<\/p>\n\n\n\n Nie twierdz\u0119, \u017ce obs\u0142uga Dockera jest trywialna, ale stawiam tez\u0119, \u017ce jak kto\u015b raz spr\u00f3buje, to ju\u017c nie wr\u00f3ci<\/strong> do wymagaj\u0105cych instalacji i \u017cmudnej konfiguracji wersji desktopowych.<\/p>\n\n\n\n Istnieje te\u017c znaczna oszcz\u0119dno\u015b\u0107 przestrzeni dyskowej. Instalacja natywnego narz\u0119dzia prawie zawsze zajmuje wielokrotnie wi\u0119cej miejsca na dysku ni\u017c obraz dockerowy.<\/p>\n\n\n\n Do minus\u00f3w i niedogodno\u015bci<\/strong> nale\u017cy jednokrotna instalacja samego Dockera. Jest to narz\u0119dzie konsolowe, ale w systemie Windows mo\u017cna korzysta\u0107 w Docker Desktop, kt\u00f3re umo\u017cliwia przejrzyste zarz\u0105dzanie obrazami i kontenerami Dockera.<\/p>\n\n\n\n Trzeba te\u017c przyzna\u0107, \u017ce musimy opanowa\u0107 konsolowe komendy, kt\u00f3re pozwol\u0105 swobodnie porusza\u0107 si\u0119 w Dockerze. Jest to jednak g\u0142\u00f3wnie wysi\u0142ek czasowy, bo z pe\u0142nym przekonaniem twierdz\u0119, \u017ce darmowe \u017ar\u00f3d\u0142a wiedzy na ten temat<\/a> w sieci s\u0105 wystarczaj\u0105ce i nie ma potrzeby inwestowa\u0107 w p\u0142atne szkolenia<\/strong> w przypadku testera manualnego.<\/p>\n\n\n\n Programi\u015bci ju\u017c docenili Dockera i czerpi\u0105 z niego pe\u0142nymi gar\u015bciami. Kontener z dowoln\u0105 aplikacj\u0105 uruchamiamy b\u0142yskawicznie (kwestia milisekund), korzystamy z niej i zamykamy r\u00f3wnie szybko. Kiedy zapis stanu aplikacji nie ma dla nas znaczenia, to sprawa jest zupe\u0142nie bezproblemowa. Nie ma r\u00f3wnie\u017c k\u0142opotu, gdy potrzebna jest komunikacja mi\u0119dzy dyskiem lokalnym a kontenerem np. poprzez wys\u0142anie pliku do kontenera lub odebranie pliku z kontenera na dysk.<\/p>\n\n\n\n Mo\u017cliwe jest tak\u017ce uruchomienie wielu kontener\u00f3w jednocze\u015bnie i po\u0142\u0105czenie ich w jedn\u0105 sie\u0107 \u2013 Network.<\/em><\/p>\n\n\n\n Pojawi\u0142o si\u0119 jednak wyzwanie dla testowania aplikacji, kt\u00f3re korzystaj\u0105 z kontener\u00f3w, zw\u0142aszcza tych opartych na architekturze mikroserwisowej. Testy integracyjne to faza, podczas kt\u00f3rej chcemy zbada\u0107 wsp\u00f3lne dzia\u0142anie r\u00f3\u017cnych komponent\u00f3w systemu np. API Restowe i baza danych czy te\u017c mikroserwis produkuj\u0105cy wiadomo\u015bci na Kafk\u0119 i konsumuj\u0105cy te wiadomo\u015bci wraz z brokerem kafkowym.<\/p>\n\n\n\n Przygotowuj\u0105c automatyczne testy integracyjne dla takiej architektury, niezb\u0119dne jest wykorzystanie kontenera bazy danych<\/strong> np. PostgreSQL czy kolejki np. Kafka. Kontener ten musi by\u0107 uruchamiany w kodzie.<\/p>\n\n\n\n Tutaj w\u0142a\u015bnie na scen\u0119 wchodzi Testcontainers. Jest to biblioteka, kt\u00f3ra dostarcza API do obs\u0142ugi kontener\u00f3w dockerowych w kodzie<\/strong>. Narz\u0119dzie obs\u0142uguje nast\u0119puj\u0105ce j\u0119zyki programowania:<\/p>\n\n\n\n Biblioteka dostarcza automatyczne zarz\u0105dzanie uruchamianiem i zamykanie kontener\u00f3w zaraz po zako\u0144czonym te\u015bcie. To niezwykle \u201eestetyczne\u201d podej\u015bcie. \u015arodowisko testowanej aplikacji jest budowane stosunkowo szybko (ok. 2-3 dodatkowe sekundy) automatycznie zaraz przed testem. Nast\u0119pnie wykonywana jest logika naszych scenariuszy i zwracany rezultat, a na koniec kontener znika bezpowrotnie.<\/p>\n\n\n\n Ta \u201eefemeryczno\u015b\u0107\u201d dla testera automatyzuj\u0105cego jest niezwykle atrakcyjna. Testcontainers dostarcza mechanizm przygotowania \u201ew locie\u201d danych testowych. Znika r\u00f3wnie\u017c potrzeba czyszczenia stanu po te\u015bcie w trosce o to, by artefakty i pozostawione dane nie wp\u0142ywa\u0142y przypadkiem na nast\u0119pne egzekucje tego samego testu. Tutaj ka\u017cde uruchomienie testu posiada w\u0142asn\u0105, \u201e\u015bwie\u017c\u0105\u201d instancj\u0119 komponentu, kt\u00f3ra ginie po te\u015bcie wraz z ca\u0142\u0105 swoj\u0105 zawarto\u015bci\u0105.<\/p>\n\n\n\n Obiekt, kt\u00f3ry zarz\u0105dza zamykaniem wybranych kontener\u00f3w to \u201etestcontainers\/ryuk<\/strong>\u201d. Uruchamia si\u0119 zawsze, mimo i\u017c wprost nie deklarujemy tego w kodzie. To kontener uprzywilejowany<\/strong>, kt\u00f3ry odpowiada za prawid\u0142owe i automatyczne zamykanie kontener\u00f3w [automatic cleanup].<\/em><\/p>\n\n\n\n Mechanizm ten ma du\u017ce znaczenie zw\u0142aszcza, kiedy ko\u0144czymy egzekucj\u0119 test\u00f3w w niestandardowy spos\u00f3b np.:<\/p>\n\n\n\n Wszystkie te i podobne sytuacje powoduj\u0105 wymuszenie zamkni\u0119cia uruchomionych kontener\u00f3w, aby nie pozostawi\u0107 w pami\u0119ci \u201emartwych kontener\u00f3w\u201d. <\/em>Dokumentacja biblioteki pozwala wprawdzie na w\u0142asn\u0105 konfiguracj\u0119 ryuk,<\/strong> a nawet wy\u0142\u0105czenie go, ale jest to niewskazane.<\/p>\n\n\n\n Przedstawi\u0119 praktyczny przyk\u0142ad u\u017cycia Testcontainers w kodzie Java. Chc\u0119 wykorzysta\u0107 baz\u0119 danych PostgreSQL jako komponent podczas testowania kontrolera [Controller<\/em>] w prostym microservice. Wybra\u0142em framework Micronaut, ale r\u00f3wnie dobrze zadzia\u0142a to z tradycyjnym Spring Boot.<\/p>\n\n\n\n Serwis to klasyczny CRUD \u2013 pozwala na odczyt, zapis, edycj\u0119 i usuwanie encji Actor do bazy danych. Posiada podzia\u0142 na warstwy:<\/p>\n\n\n\n W Micronaucie taka klasa modelowa b\u0119dzie wygl\u0105da\u0142a nast\u0119puj\u0105co:<\/p>\n\n\n Zdefiniowa\u0142em DataSource w pliku konfiguracyjnym application.yml<\/strong> dla Postgresa, kt\u00f3ry wygl\u0105da nast\u0119puj\u0105co:<\/p>\n\n\n Kiedy baza danych z odpowiednim schematem jest uruchomiona, wszystko dzia\u0142a bez zarzutu. Mog\u0119 wykona\u0107 moje testy API napisane np. w RestAssured. Je\u015bli jednak wy\u0142\u0105cz\u0119 baz\u0119 danych, \u017caden test nie da wiarygodnych rezultat\u00f3w. Testcontainer pozwoli mi na \u201ew\u0142\u0105czenie\u201d brakuj\u0105cego komponentu tylko na czas wykonania moich test\u00f3w.<\/p>\n\n\n\n Pierwszym krokiem jest pobranie zale\u017cno\u015bci do projektu:<\/p>\n\n\n\n Maven<\/strong>:<\/p>\n\n\n Gradle<\/strong>:<\/p>\n\n\n Nast\u0119pnie definiuj\u0119 DataSource na poziomie test\u00f3w. W Micronaut odpowiedzialny jest za to plik konfiguracyjny application-test.yml:<\/strong><\/p>\n\n\n Zwr\u00f3\u0107cie uwag\u0119, \u017ce parametr url<\/em> jest oznaczony przez tc<\/strong> \u2013 [jdbc:tc] \u2013 co wskazuje, \u017ce jego obs\u0142ug\u0105 zajmie si\u0119 Testcontainers. Dodatkowo, driverClassName <\/em>r\u00f3wnie\u017c zawiera wskazanie na pakiet org.testcontainers.<\/p>\n\n\n\n Teraz ju\u017c mo\u017cemy w kodzie klasy testowej zaznaczy\u0107, \u017ce b\u0119dziemy wykorzystywali kontenery Dockera poprzez adnotacj\u0119 @Testcontainers<\/strong> przed klas\u0105.<\/p>\n\n\n oraz adnotacj\u0105 @Container<\/strong> przed polem, kt\u00f3ry definiuje typ I wersj\u0119 kontenera:<\/p>\n\n\n Pozosta\u0142e adnotacje to:<\/p>\n\n\n\n Klasa PostgreSQLContainer <\/em>zapewnia nam prawid\u0142ow\u0105 obs\u0142ug\u0119 tego szczeg\u00f3\u0142owego kontenera PostgreSQL. Istnieje ponadto generyczna klasa GenericContainer<\/em>, kt\u00f3r\u0105 zawsze mo\u017cemy wykorzysta\u0107 do przechowania obiektu dowolnego kontenera:<\/p>\n\n\n Biblioteka Testcontainers wymaga, aby\u015bmy dodali absolutnie minimaln\u0105 i niezb\u0119dn\u0105 konfiguracj\u0119 naszego kontenera. Musimy przecie\u017c wybra\u0107, jaki image postgres potrzebujemy, zdefiniowa\u0107 nazw\u0119 schematu, username i password.<\/p>\n\n\n\n Osobi\u015bcie preferuj\u0119 umieszczenie takiej konfiguracji nie w klasie testowej, ale w osobnej klasie odpowiedzialnej za kontenery postgresa. Ma to sens, poniewa\u017c postgres to nie jedyny komponent, jakiego potencjalnie mo\u017cemy potrzebowa\u0107. Gdy pojawi si\u0119 Kafka, Redis czy MongoDB, to bezpiecznie odseparujemy wszystkie te konfiguracje.<\/strong><\/p>\n\n\n\n Kod takiej klasy mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n\n\n Najistotniejsza jest tu statyczna metoda \u2013 getContainerPostgres<\/em>(). To tutaj za pomoc\u0105 wielu metod rozpoczynaj\u0105cych si\u0119 od \u201ewith\u201d ustawiamy stan naszego kontenera oraz sposoby \u0142\u0105czenia si\u0119 z nim.<\/p>\n\n\n\n Tryb \u0142a\u0144cuchowego wywo\u0142ania tych metod dodaje ogromnej wygody:<\/p>\n\n\n\n Teraz pozostaje ju\u017c tylko przekazanie do testowego DataSource szczeg\u00f3\u0142\u00f3w po\u0142\u0105czenia z kontenerow\u0105 baz\u0105 danych. Wraz z micronautow\u0105 adnotacj\u0105 @MockBean jest to bardzo proste i mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co w klasie testowej:<\/p>\n\n\n Widoczny w klasie bean JdbcTemplate pos\u0142u\u017cy\u0142 mi tylko jako connector do bazy danych. To dzi\u0119ki niemu b\u0119dziemy wiedzieli, \u017ce baza danych rzeczywi\u015bcie pojawi si\u0119, kiedy jej potrzebujemy, bo b\u0119dziemy mogli wykona\u0107 nasze zapytania i odebra\u0107 rezultaty.<\/p>\n\n\n\n Kiedy wszystko jest przygotowane mog\u0119 zaimplementowa\u0107 dwa proste testy:<\/p>\n\n\n\n Oto rezultaty klasy testowej uruchomionej lokalnie w IDE. Zwr\u00f3\u0107 uwag\u0119, jak logi w konsoli wyra\u017anie wskazuj\u0105, \u017ce:<\/p>\n\n\n\n I co najwa\u017cniejsze \u2013 czas wykonania obu test\u00f3w to zaledwie 0,5 sek!<\/strong><\/p>\n\n\n\n Dodatkowo, na potwierdzenie dodaj\u0119 jeszcze widok z Docker Desktop w czasie wykonania test\u00f3w. Wida\u0107 wyra\u017anie, \u017ce potrzebne kontenery s\u0105 w statusie running:<\/p>\n\n\n\n Mo\u017cna zauwa\u017cy\u0107, jak Testcontainer pozwoli\u0142 mi minimalnym wysi\u0142kiem implementowa\u0107 dowolne testy integracyjne. Niezb\u0119dne komponenty \u201ewstaj\u0105\u201d w postaci kontener\u00f3w dockerowych, a po wykonanym te\u015bcie komponenty te s\u0105 usuwane.<\/p>\n\n\n\n Jest jeszcze jedno zagadnienie, kt\u00f3re uznaj\u0119 jako niezwykle przydatne w Testcontainers. S\u0105 to opcje (flagi), kt\u00f3re definiuj\u0119 w pliku konfiguracyjnym<\/strong> application-test.yml:<\/em><\/p>\n\n\n\n Zrozumia\u0142e jest, \u017ce kiedy korzystamy z bazy danych, chcieliby\u015bmy, \u017ceby ju\u017c by\u0142 tam schemat, tabele i jakie\u015b dane testowe niezb\u0119dne do wykonania testu. Dzi\u0119ki opcji TC_INITSCRIPT, mo\u017cemy zdefiniowa\u0107 skrypt SQL, kt\u00f3ry wykona si\u0119 zaraz po uruchomieniu kontenera DB, ale przed wykonaniem pierwszej linijki kodu.<\/p>\n\n\n\n W moim demo wykorzysta\u0142em nast\u0119puj\u0105cy skrypt, dzi\u0119ki czemu nie musia\u0142em w kodzie testu obs\u0142ugiwa\u0107 zawarto\u015bci mojej bazy PostgreSQL:<\/p>\n\n\n\n W domy\u015blnym ustawieniu kontener bazy danych jest zatrzymywany po zamkni\u0119ciu ostatniego po\u0142\u0105czenia. Bywaj\u0105 jednak sytuacje, w kt\u00f3rych b\u0119dziemy chcieli, aby kontener dzia\u0142a\u0142 do momentu jego wyra\u017anego zatrzymania lub wy\u0142\u0105czenia maszyny JVM. Aby to zrobi\u0107, dodaj parametr TC_DAEMON do adresu URL jak w grafice wy\u017cej.<\/p>\n\n\n\n Testcontainers to biblioteka do obs\u0142ugi kontener\u00f3w dockerowych w kodzie. Doskonale sprawdza si\u0119<\/strong> podczas tworzenia efemerycznych komponent\u00f3w w zautomatyzowanych testach integracyjnych. Pozwala te\u017c na za\u0142adowanie skrypt\u00f3w SQL w taki spos\u00f3b, \u017ce kontenerowa baza danych jest ju\u017c wyposa\u017cona w schemat i dane niezb\u0119dne do test\u00f3w.<\/p>\n\n\n\n Podczas pracy w Testcontainers zauwa\u017cy\u0142em dwie niedogodno\u015bci<\/strong>:<\/p>\n\n\n\n ***<\/a><\/a>Zalety i wady rozwi\u0105zania<\/strong><\/h3>\n\n\n\n
<\/a>Docker dla testera automatyzuj\u0105cego i programisty<\/strong><\/h2>\n\n\n\n
Testcontainers<\/strong><\/h2>\n\n\n\n
<\/a>Testcontainers\/ryuk<\/strong><\/h3>\n\n\n\n
Testcontainers dla j\u0119zyka JAVA \u2013 demo<\/strong><\/h2>\n\n\n\n
\npackage com.example;\n\nimport io.micronaut.core.annotation.Nullable;\nimport io.micronaut.data.annotation.GeneratedValue;\nimport io.micronaut.data.annotation.MappedEntity;\nimport io.swagger.v3.oas.annotations.media.Schema;\nimport javax.persistence.Entity;\nimport javax.persistence.GenerationType;\nimport javax.persistence.Id;\nimport javax.validation.constraints.NotBlank;\nimport javax.validation.constraints.Size;\n\n@Schema(description="Actor business model")\n@Entity\npublic class Actor\n {\n @GeneratedValue @Id\n @Nullable\n private Long id;\n @NotBlank @Size(max = 20)\n private String firstName;\n @NotBlank @Size(max = 20)\n private String lastName;\n @NotBlank\n private Long rating;\n\n\/\/getters and setters\n}\n[src\/main\/java\/model\/Actor] \n<\/pre><\/div>\n\n\n\ndatasources:\n default:\n url: jdbc:postgresql:\/\/localhost:5432\/actor\n driverClassName: org.postgresql.Driver\n username: postgres\n password: postgres\n schema-generate: NONE\n dialect: POSTGRES\n schema: public\n<\/pre><\/div>\n\n\n
\n<dependency>\n <groupId>org.junit.jupiter<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>5.8.1<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>testcontainers<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<\/pre><\/div>\n\n\n
\ntestImplementation "org.junit.jupiter:junit-jupiter:5.8.1"\ntestImplementation "org.testcontainers:testcontainers:1.17.6"\ntestImplementation "org.testcontainers:junit-jupiter:1.17.6"\n<\/pre><\/div>\n\n\n
\ndatasources:\ndefault:\nurl: jdbc:tc:postgresql:latest:\/\/\/postgres?TC_INITSCRIPT=file:src\/test\/resources\/init-actor-testdata.sql?TC_DAEMON=true\n \tdriverClassName: org.testcontainers.jdbc.ContainerDatabaseDriver\n \tminimum-idle: 5\n<\/pre><\/div>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n}\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\n\n@Container\n private static final GenericContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n<\/pre><\/div>\n\n\n
\npackage com.example.containers;\n\nimport org.testcontainers.containers.PostgreSQLContainer;\nimport org.testcontainers.utility.DockerImageName;\n\npublic class PostgresContainer extends PostgreSQLContainer<PostgresContainer> {\n private static final String MYPOSTGRESIMAGE = "postgres:latest" ;\n private static final String MYTESTDATABASENAME = "actor";\n private static final String USERNAME = "postgres";\n private static final String PASSWD = "postgres";\n private static final Integer DB_PORT = 5432;\n\n private PostgresContainer() {\n super(DockerImageName.parse(MYPOSTGRESIMAGE));\n }\n\n public static PostgreSQLContainer<?> getContainerPostgres() {\n return new PostgreSQLContainer<>(DockerImageName.parse(MYPOSTGRESIMAGE))\n .withDatabaseName(MYTESTDATABASENAME)\n .withExposedPorts(DB_PORT)\n .withUsername(USERNAME)\n .withPassword(PASSWD);\n }\n}\n[src\/test\/containers\/PostgresContainer]\n<\/pre><\/div>\n\n\n<\/figure>\n\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n private DataSource postgresDataSource;\n\n private JdbcTemplate jdbcTemplate;\n\n @Inject\n public JdbcTemplateExampleTest(DataSource postgresDataSource) {\n this.postgresDataSource = postgresDataSource;\n }\n\n @MockBean(DBConnector.class)\n DBConnector postgresConnection() {\n PostgresTestContainer dbConnection = new PostgresTestContainer();\n dbConnection.setUrl(postgres.getJdbcUrl());\n dbConnection.setUsername(postgres.getUsername());\n dbConnection.setPasswd(postgres.getPassword());\n return dbConnection;\n }\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\n\n@Test\n void shouldGetAllActorsFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getLoadedRecords();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults.get(0).get("firstname")).isEqualTo("Brad");\n assertThat(dbResults.get(1).get("firstname")).isEqualTo("Angelina");\n assertThat(dbResults.get(2).get("firstname")).isEqualTo("Salma");\n }\n\n @Test\n void shouldGetSingleActorFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getSingleRecord();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults).isEqualTo("Brad");\n }\n\n private boolean isRecordLoaded() {\n return jdbcTemplate.queryForList("Select * from actor").size() > 1;\n }\n\n private List<Map<String, Object>> getLoadedRecords() {\n return jdbcTemplate.queryForList("Select * from actor");\n }\n\n private String getSingleRecord() {\n return jdbcTemplate.queryForObject("Select firstname from actor where id=1", String.class);\n }\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nWyniki<\/strong><\/h3>\n\n\n\n
<\/a><\/a>TC_INITSCRIPT<\/strong><\/h3>\n\n\n\n
<\/a>TC_DAEMON<\/strong><\/h3>\n\n\n\n
Podsumowanie<\/strong><\/h2>\n\n\n\n
Je\u017celi interesuje Ci\u0119 temat Dockera, zach\u0119camy do przeczytania serii artyku\u0142\u00f3w przygotowanych przez naszego eksperta:<\/p>\n\n\n\n