streamalism.org

1. Introduksjon

I denne opplæringen ser vi på Java Testbeholdere bibliotek. Det lar oss bruke Docker-containere i testene våre. Som et resultat kan vi skrive selvstendige integrasjonstester som avhenger av eksterne ressurser.

Vi kan bruke hvilken som helst ressurs i testene våre som har et dockerbilde. For eksempel er det bilder for databaser, nettlesere, webservere og meldingskøer. Derfor kan vi kjøre dem som containere i testene våre.

2. Krav

Testbeholdere biblioteket kan brukes med Java 8 og nyere. Dessuten er den kompatibel med JUnit Rules API.

La oss først definere den avhengige avhengigheten for kjernefunksjonaliteten:

 org.testcontainers testcontainers 1.11.4 

Det er også moduler for spesialiserte containere. I denne opplæringen bruker vi PostgreSQL og Selen.

La oss legge til relevante avhengigheter:

 org.testcontainers postgresql 1.11.4 org.testcontainers selen 1.11.4 

Vi finner de nyeste versjonene på Maven Central.

Vi trenger også Docker for å kjøre containere. Se Docker-dokumentasjonen for installasjonsinstruksjoner.

Forsikre deg om at du kan kjøre Docker-containere i testmiljøet ditt.

3. Bruk

La oss konfigurere en generell containerregel:

@ClassRule offentlig statisk GenericContainer simpleWebServer = ny GenericContainer ("alpine: 3.2") .withExposedPorts (80) .withCommand ("/ bin / sh", "-c", "while true; do echo" + "\" HTTP / 1.1 200 OK \ n \ n Hallo verden! \ "| Nc -l -p 80; ferdig");

Vi konstruerer en GenericContainer testregel ved å spesifisere navnet på dockerbildet. Deretter konfigurerer vi det med byggemetoder:

• Vi bruker medExposedPorts å avsløre en port fra containeren
• withCommand definerer en containerkommando. Den vil bli utført når containeren starter.

Regelen er kommentert med @ClassRule. Som et resultat vil den starte Docker-beholderen før en test i den klassen kjøres. Containeren blir ødelagt etter at alle metodene er utført.

Hvis du søker @Regel kommentar, GenericContainer regelen starter en ny container for hver testmetode. Og det vil stoppe beholderen når testmetoden er ferdig.

Vi kan bruke IP-adresse og port for å kommunisere med prosessen som kjører i containeren:

@Test offentlig ugyldighet givenSimpleWebServerContainer_whenGetReuqest_thenReturnsResponse () kaster unntak {String address = "//" + simpleWebServer.getContainerIpAddress () + ":" + simpleWebServer.getMappedPort (80); Strengrespons = simpleGetRequest (adresse); assertEquals (svar, "Hello World!"); }

4. Bruksmetoder

Det er flere bruksmodi av testbeholderne. Vi så et eksempel på å kjøre en GenericContainer.

Testbeholdere biblioteket har også regeldefinisjoner med spesialisert funksjonalitet. De er for containere med vanlige databaser som MySQL, PostgreSQL; og andre som nettklienter.

Selv om vi kan kjøre dem som generiske containere, gir spesialiseringene utvidede bekvemmelighetsmetoder.

4.1. Databaser

La oss anta at vi trenger en databaseserver for integreringstester for data-tilgang-lag. Vi kan kjøre databaser i containere ved hjelp av TestContainers-biblioteket.

For eksempel fyrer vi opp en PostgreSQL-container med PostgreSQLContainer regel. Da kan vi bruke hjelpemetoder. Disse er getJdbcUrl, getUsername, getPassword for databasetilkobling:

@Rule public PostgreSQLContainer postgresContainer = ny PostgreSQLContainer (); @Test offentlig ugyldig nårSelectQueryExecuted_thenResulstsReturned () kaster unntak {String jdbcUrl = postgresContainer.getJdbcUrl (); String brukernavn = postgresContainer.getUsername (); Strengpassord = postgresContainer.getPassword (); Connection connect = DriverManager .getConnection (jdbcUrl, brukernavn, passord); ResultSet resultSet = conn.createStatement (). ExecuteQuery ("SELECT 1"); resultSet.next (); int resultat = resultSet.getInt (1); assertEquals (1, resultat); }

Det er også mulig å kjøre PostgreSQL som en generisk container. Men det ville være vanskeligere å konfigurere forbindelsen.

4.2. Nettdrivere

Et annet nyttig scenario er å kjøre containere med nettlesere. BrowserWebDriverContainer regel muliggjør kjøring Chrome og Firefox i docker-selen containere. Så klarer vi dem med RemoteWebDriver.

Dette er veldig nyttig for å automatisere UI / aksepttester for webapplikasjoner:

@Rule public BrowserWebDriverContainer chrome = new BrowserWebDriverContainer () .withCapabilities (new ChromeOptions ()); @Test offentlig ugyldig nårNavigatedToPage_thenHeadingIsInThePage () {RemoteWebDriver driver = chrome.getWebDriver (); driver.get ("// eksempel.com"); Strengoverskrift = driver.findElement (By.xpath ("/ html / body / div / h1")) .getText (); assertEquals ("Eksempel domene", overskrift); }

4.3. Docker komponere

Hvis testene krever mer komplekse tjenester, kan vi spesifisere dem i a docker-compose fil:

simpleWebServer: image: alpine: 3.2 kommando: ["/ bin / sh", "-c", "while true; echo 'HTTP / 1.1 200 OK \ n \ nHello World!' | nc -l -p 80; ferdig "]

Så bruker vi DockerComposeContainer regel. Denne regelen starter og kjører tjenester som definert i komponentfilen.

Vi bruker getServiceHost og getServicePost metoder for å bygge tilkoblingsadresse til tjenesten:

@ClassRule offentlig statisk DockerComposeContainer compose = ny DockerComposeContainer (ny fil ("src / test / resources / test-compose.yml")) .withExposedService ("simpleWebServer_1", 80); @Test offentlig ugyldighet givenSimpleWebServerContainer_whenGetReuqest_thenReturnsResponse () kaster unntak {String address = "//" + compose.getServiceHost ("simpleWebServer_1", 80) + ":" + compose.getServicePort ("simpleWebServer_1", 80); Strengrespons = simpleGetRequest (adresse); assertEquals (svar, "Hello World"); }

5. Konklusjon

Vi så hvordan vi kunne bruke Testbeholdere bibliotek. Det letter utviklingen og kjøringen av integrasjonstester.

Vi brukte GenericContainer regel for containere med gitt dockerbilder. Så så vi på PostgreSQLContainer, BrowserWebDriverContainer og DockerComposeContainer regler. De gir mer funksjonalitet for spesifikke brukssaker.

Til slutt, kodeeksempler her kan du finne på GitHub.