Testų konteineriai - kaip palengvinti testus?

Šiuolaikinis programų kūrimas grindžiamas viena paprasta taisykle:

Naudokite sudėtį

Klases, funkcijas ir paslaugas sujungiame į didesnius programinės įrangos vienetus. Pastarasis elementas yra mikroservisai ir šešiakampė architektūra. Norėtume naudoti esamus sprendimus, integruoti juos į savo programinę įrangą ir iš karto pereiti prie rinka.

Ar norite tvarkyti paskyros registraciją ir saugoti naudotojo duomenys? Galite pasirinkti vieną iš OAuth paslaugų. Galbūt jūsų programa siūlo kokią nors prenumeratą ar mokėjimą? Yra daugybė paslaugų, kurios gali padėti tai tvarkyti. Ar jums reikia tam tikros svetainės analizės, bet nesuprantate, kaip ją atlikti? BDAR? Drąsiai rinkitės vieną iš paruoštų sprendimų.

Tai, kas verslo požiūriu taip palengvina kūrimą, gali sukelti galvos skausmą, kai reikia parašyti paprastą testą.

Filmas "Fantastiniai žvėrys: Eilės, duomenų bazės ir kaip jas išbandyti

Vieneto testavimas yra gana paprastas. Jei tik laikysitės taisyklių, jūsų testavimo aplinka ir kodas yra sveiki. Kokios tai taisyklės?

• Lengva rašyti - vienetinį testą turėtų būti lengva parašyti, nes jų rašote daug. Mažiau pastangų reiškia, kad parašoma daugiau testų.
• Įskaitomas - testo kodą turėtų būti lengva perskaityti. Testas yra istorija. Jis aprašo programinės įrangos elgesį ir gali būti naudojamas kaip dokumentacijos sutrumpinimas. Geras vieneto testas padeda ištaisyti klaidas negadinant kodo.
• Patikimas - testas turėtų būti nesėkmingas tik tuo atveju, jei testuojamoje sistemoje yra klaida. Akivaizdu? Ne visada. Kartais testai būna sėkmingi, jei juos paleidžiate po vieną, bet nesėkmingi, jei juos paleidžiate kaip rinkinį. Jie praeina jūsų kompiuteryje, bet nepavyksta CI (Veikia mano kompiuteryje). Geras vieneto testas turi tik vieną nesėkmės priežastį.
• Greitai - testai turėtų būti greiti. Pasirengimas paleisti, paleidimas ir pats testo vykdymas turėtų būti labai greitas. Priešingu atveju juos parašysite, bet neįvykdysite. Lėti testai reiškia prarastą dėmesį. Lauksite ir žiūrėsite į pažangos juostą.
• Nepriklausomas - galiausiai testas turėtų būti nepriklausomas. Ši taisyklė išplaukia iš ankstesnių. Tik tikrai nepriklausomi testai gali tapti vienetu. Jie vienas kitam netrukdo, gali būti vykdomi bet kokia tvarka, o galimos nesėkmės nepriklauso nuo kitų testų rezultatų. Nepriklausomi testai taip pat reiškia, kad jie nepriklauso nuo jokių išorinių išteklių, pavyzdžiui, duomenų bazių, pranešimų perdavimo paslaugų ar failų sistemos. Jei reikia bendrauti su išoriniais ištekliais, galite naudoti maketus, stubus arba manekenus.

Viskas tampa sudėtinga, kai norime parašyti keletą integracijos testų. Neblogai, jei norime testuoti kelias paslaugas kartu. Tačiau kai reikia testuoti paslaugas, kurios naudoja išorinius išteklius, pavyzdžiui, duomenų bazes ar pranešimų siuntimo paslaugas, tuomet prašomės problemų.

Norėdami atlikti testą, turite įdiegti...

Prieš daugelį metų, kai norėjome atlikti tam tikrus integracijos testus ir naudoti, pavyzdžiui, duomenų bazes, turėjome dvi galimybes:

1. Duomenų bazę galime įdiegti vietoje. Nustatykite schemą ir prisijunkite iš mūsų bandymo;
2. Galime prisijungti prie esamo egzemplioriaus "kažkur erdvėje".

Abu turėjo privalumų ir trūkumų. Tačiau abiem atvejais atsiranda papildomų sudėtingumo lygių. Kartais tai buvo techninis sudėtingumas, atsirandantis dėl tam tikrų įrankių savybių, pvz., "Oracle" DB diegimas ir valdymas vietiniame prieglobstyje. Kartais tai buvo proceso nepatogumai, pvz., reikia susitarti su testo komanda apie JMS naudojimą... kiekvieną kartą, kai norite paleisti testus.

Konteineriai į pagalbą

Per pastaruosius 10 metų konteinerizavimo idėja sulaukė pripažinimo pramonėje. Todėl natūralu, kad mūsų integracijos testų problemai spręsti pasirinksime konteinerius. Tai paprastas, švarus sprendimas. Tiesiog paleidžiate savo proceso kūrimą ir viskas veikia! Negalite tuo patikėti? Pažvelkite į šią paprastą "Maven" sąrankos konfigūraciją:

com.dkanejs.maven.plugins
     docker-compose-maven-plugin
     4.0.0
     
       
         į viršų
         test-compile
         
           į viršų
         
         
           ${projektas.basedir}/docker-compose.yml
           true
         
       
       
         į apačią
         post-integration-test
         
           išjungimas
         
         
           ${project.basedir}/docker-compose.yml
           true

Ir docker-compose.yml failas taip pat atrodo gana gražiai!

versija: "3.5"

paslaugos:

 Postgres:
   Konteinerio_vardas: reactivedb
   vaizdas: postgres:13.2
   restart: always
   aplinka:
     - POSTGRES_USER=admin
     - POSTGRES_PASSWORD=password
     - POSTGRES_DB=cities
   portai:
     - "5432:5432"
   tomai:
     - postgres_data:/data/db

 pgadmin:
   konteinerio_vardas: pgadmin4
   vaizdas: dpage/pgadmin4
   restart: always
   aplinka:
     PGADMIN_DEFAULT_EMAIL: [email protected]
     PGADMIN_DEFAULT_PASSWORD: password
   prievadai:
     - "15050:80"
   tomai:
     - pgadmin_data:/data/pgadmin

tomai:
 postgres_data:
 pgadmin_data:

Tačiau ar galite pastebėti problemą?

Viską blokuojantis krovininis laivas

Pateiktas pavyzdys yra labai paprastas. Tik viena postgres duomenų bazė, pgAdmin ir viskas. Kai paleidžiate

bash
$ mvn švarus patikrinti

tada "maven" įskiepis paleidžia konteinerius ir po testų juos išjungia. Problemos prasideda tada, kai projektas auga ir mūsų sudėtinis failas taip pat auga. Kiekvieną kartą reikės paleisti visus konteinerius, ir jie bus gyvi per visą surinkimą. Situaciją galite šiek tiek pagerinti pakeisdami įskiepio vykdymo konfigūraciją, tačiau to nepakanka. Blogiausiu atveju jūsų konteineriai išnaudos sistemos išteklius dar prieš pradedant bandymus!

Ir tai ne vienintelė problema. Negalite paleisti nė vieno integracijos testo iš savo IDE. Prieš tai konteinerius reikia paleisti rankiniu būdu. Be to, kitas "maven" paleidimas tuos konteinerius išardys (žr. žemyn vykdymas).

Taigi šis sprendimas yra tarsi didelis krovininis laivas. Jei viskas gerai veikia, viskas gerai. Bet koks netikėtas ar neįprastas elgesys lemia mus į kokią nors nelaimę.

Testavimo konteineriai - paleiskite konteinerius iš testų

O jei galėtume paleisti konteinerius iš testų? Ši idėja atrodo gera, ir ji jau įgyvendinama. Bandomosios talpyklosKadangi kalbame apie šį projektą, čia pateikiamas mūsų problemų sprendimas. Ne idealus, bet niekas nėra tobulas.

Tai yra Java biblioteka, kuri palaiko "JUnit" ir "Spock" testus, suteikdama lengvus ir paprastus būdus paleisti "Docker" konteineris. Pažvelkime į jį ir parašykime šiek tiek kodo!

Būtinosios sąlygos ir konfigūracija

Prieš pradėdami turime patikrinti savo konfigūraciją. Bandomosios talpyklos reikia:

• "Docker" versija v17.09,
• Minimali "Java" versija 1.8,
• Prieiga prie tinklo, ypač prie docker.hub.

Daugiau informacijos apie konkrečios OS ir CI reikalavimus rasite
svetainėje dokumentacija.

Dabar metas pridėti keletą eilučių į pom.xml.

org.testcontainers
       testcontainers-bom
       ${testcontaines.version}
       pom
       import
     
   
 
 
   
     org.postgresql
     postgresql
     runtime
   
   
     org.testcontainers
     postgresql
     test
   
   
     org.testcontainers
     junit-jupiter
     test

Aš naudoju Bandomosios talpyklos versija 1.17.3, tačiau galite naudoti naujausią.

Bandymai su "Postgres" konteineriu

Pirmasis žingsnis - paruošti konteinerio egzempliorių. Tai galite padaryti tiesiogiai teste, tačiau geriau atrodo nepriklausoma klasė.

viešoji klasė Postgres13TC extends PostgreSQLContainer {

 private static final Postgres13TC TC = new Postgres13TC();

 private Postgres13TC() {
   super("postgres:13.2");
 }

 public static Postgres13TC getInstance() {
   return TC;
 }

 @Override
 public void start() {
   super.start();
   System.setProperty("DB_URL", TC.getJdbcUrl());
   System.setProperty("DB_USERNAME", TC.getUsername());
   System.setProperty("DB_PASSWORD", TC.getPassword());
 }

 @Override
 public void stop() {
   // nieko nedaryti. Tai bendrinamas egzempliorius. Leiskite JVM atlikti šią operaciją.
 }
}

Testų pradžioje sukursime egzempliorių Postgres13TC. Šioje klasėje galima tvarkyti informaciją apie konteinerį. Svarbiausia čia yra duomenų bazės ryšio eilutės ir įgaliojimai. Dabar metas parašyti labai paprastą testą.

@Testcontainers
klasė SimpleDbTest {

 @Container
 private static Postgres13TC = Postgres13TC.getInstance();

 @Test
 void testConnection() {
   assumeThat(postgres13TC.isRunning());
   var connectionProps = new Properties();
   connectionProps.put("user", postgres13TC.getUsername());
   connectionProps.put("password", postgres13TC.getPassword());

   bandymas (Connection = DriverManager.getConnection(postgres13TC.getJdbcUrl(),
       connectionProps)) {
     var resultSet = connection.prepareStatement("Select 1").executeQuery();
     resultSet.next();
     assertThat(resultSet.getInt(1)).isEqualTo(1);
   } catch (SQLException sqlException) {
     assertThat((Exception) sqlException).doesNotThrowAnyException();
   }
 }
}

Čia naudoju "JUnit 5". Anotacija @Testcontainers yra dalis plėtinių, kurie valdo konteinerius bandymų aplinkoje. Jie randa visus laukus su @Container anotacija ir atitinkamai "Start" bei "Stop" konteineriai.

Testai su "Spring Boot

Kaip jau minėjau, projekte naudoju "Spring Boot". Šiuo atveju reikia parašyti šiek tiek daugiau kodo. Pirmasis žingsnis - sukurti papildomą konfigūracijos klasę.

@Slf4j
public class ContainerInit implements
   ApplicationContextInitializer {

 public static Postgres13TC;

 static {
   postgres13TC = Postgres13TC.getInstance();
   postgres13TC.start();
 }

 @Override
 public void initialize(ConfigurableApplicationContext applicationContext) {
   TestPropertySourceUtils.addInlinedPropertiesToEnvironment(
       applicationContext,
       "spring.datasource.url=" + postgres13TC.getJdbcUrl(),
       "spring.datasource.username=" + postgres13TC.getUsername(),
       "spring.datasource.password=" + postgres13TC.getPassword(),
       "db.host=" + postgres13TC.getHost(),
       "db.port=" + postgres13TC.getMappedPort(postgres13TC.POSTGRESQL_PORT),
       "db.name=" + postgres13TC.getDatabaseName(),
       "db.username=" + postgres13TC.getUsername(),
       "db.password=" + postgres13TC.getPassword()
   );
 }
}

Ši klasė pakeičia esamas savybes reikšmėmis iš bandomoji talpykla. Pirmosios trys savybės yra standartinės "Spring" savybės. Kitos penkios yra papildomos, pasirinktinės savybės, kurias galima naudoti kitiems ištekliams ir plėtiniams, pvz., liquibase, konfigūruoti:

spring.liquibase.change-log=classpath:/db/changelog/dbchangelog.xml
spring.liquibase.url=jdbc:postgresql://${db.host:localhost}:${db.port:5432}/${db.name:cities}
spring.liquibase.user=${db.username:admin}
spring.liquibase.password=${db.password:password}
spring.liquibase.enabled=true

Dabar laikas apibrėžti paprastą integracijos testą.

@SpringBootTest(webEnvironment = RANDOM_PORT)
@AutoConfigureTestDatabase(replace = NONE)
@ContextConfiguration(initializers = ContainerInit.class)
@Testcontainers
klasė DummyRepositoryTest {

 @Autowired
 private DummyRepository;

 @Test
 void shouldReturnDummy() {
   var byId = dummyRepository.getById(10L);
   var expected = new Dummy();
   expected.setId(10L);
   assertThat(byId).completes().emitsCount(1).emits(expected);
 }
}

Čia turime keletą papildomų pastabų.

• @SpringBootTest(webEnvironment = RANDOM_PORT) - pažymi testą kaip "Spring Boot" testą ir paleidžia "Spring" kontekstą.
• @AutoConfigureTestDatabase(replace = NONE) - šiose anotacijose teigiama, kad spring testo plėtinys neturėtų pakeisti postgres duomenų bazės konfigūracijos H2 atminties konfigūracija.
• @ContextConfiguration(initializers = ContainerInit.class) - papildomas pavasario kontekstas
  konfigūracija, kurioje nustatome savybes iš Bandomosios talpyklos.
• @Testcontainers - kaip jau minėta, ši anotacija kontroliuoja konteinerio gyvavimo ciklą.

Šiame pavyzdyje naudojau reaktyviąsias saugyklas, bet tas pats veikia ir su įprastomis JDBC ir JPA saugyklomis.

Dabar galime atlikti šį testą. Jei tai pirmas paleidimas, variklis turi ištraukti atvaizdus iš docker.hub. Tai gali užtrukti akimirką. Po to pamatysime, kad paleisti du konteineriai. Vienas iš jų yra postgres, o kitas - Testcontainers valdiklis. Tas antrasis konteineris valdo paleistus konteinerius ir net jei netikėtai sustoja JVM, jis išjungia konteinerius ir sutvarko aplinką.

Apibendrinkime

Bandomosios talpyklos yra labai lengvai naudojami įrankiai, padedantys kurti integracijos testus, kuriuose naudojami "Docker" konteineriai. Tai suteikia mums daugiau lankstumo ir padidina kūrimo greitį. Tinkamai nustačius testų konfigūraciją, sutrumpėja naujų kūrėjų įlaipinimo laikas. Jiems nereikia nustatyti visų priklausomybių, tereikia paleisti parašytus testus su pasirinktais konfigūracijos failais.