Testu konteineri - kā atvieglot testus?

Un docker-compose.yml fails arī izskatās diezgan jauki!

versija: "3.5"

pakalpojumi:

 postgres:
   konteinera_nosaukums: reactivedb
   attēls: postgres:13.2
   restart: vienmēr
   vide:
     - POSTGRES_USER=admin
     - POSTGRES_PASSWORD=password
     - POSTGRES_DB=cities
   ostas:
     - "5432:5432"
   apjomi:
     - postgres_data:/data/db

 pgadmin:
   konteinera_nosaukums: pgadmin4
   attēls: dpage/pgadmin4
   restart: vienmēr
   vide:
     PGADMIN_DEFAULT_EMAIL: [email protected]
     PGADMIN_DEFAULT_PASSWORD: password
   portus:
     - "15050:80"
   apjomi:
     - pgadmin_data:/data/pgadmin

sējumi:
 postgres_data:
 pgadmin_data:

Bet vai varat pamanīt problēmu?

Kravas kuģis, kas bloķē visu

Iepriekš minētais piemērs ir ļoti vienkāršs. Tikai viena postgres datubāze, pgAdmin un viss. Kad palaižat

bash
$ mvn tīrs pārbaudīt

tad maven spraudnis iedarbina konteinerus un pēc testu veikšanas tos izslēdz. Problēmas sākas, kad projekts pieaug un pieaug arī mūsu compose fails. Katru reizi būs nepieciešams iedarbināt visus konteinerus, un tie būs dzīvi visas kompilācijas laikā. Situāciju var nedaudz uzlabot, mainot spraudņa izpildes konfigurāciju, taču ar to nepietiek. Sliktākajā gadījumā jūsu konteineri izsmeltu sistēmas resursus, pirms sākas testi!

Un tas nav vienīgais jautājums. Jūs nevarat palaist vienu integrācijas testu no savas IDE. Pirms tam konteineri ir jāpalaiž ar rokām. Turklāt nākamais maven palaidums nojauks šos konteinerus (skat. uz leju izpilde).

Tātad šis risinājums ir kā liels kravas kuģis. Ja viss darbojas labi, tad viss ir kārtībā. Jebkāda neparedzēta vai neparasta uzvedība noved pie tā, ka mums līdz kādai katastrofai.

Testēšanas konteineri - palaist konteinerus no testiem

Bet ko tad, ja mēs varētu palaist savus konteinerus no testiem? Šī ideja izskatās laba, un tā jau tiek īstenota. Testkonteineri, jo mēs runājam par šo projektu, šeit ir mūsu problēmu risinājums. Nav ideāls, bet neviens nav ideāls.

Tas ir Java bibliotēka, kas atbalsta JUnit un Spock testus, nodrošinot vieglus un vienkāršus veidus, kā palaist Docker konteiners. Aplūkosim to un uzrakstīsim kādu kodu!

Priekšnosacījumi un konfigurācija

Pirms sākam darbu, jāpārbauda konfigurācija. Testa konteineri nepieciešams:

• Docker versijā v17.09,
• Java minimālā versija 1.8,
• Piekļuve tīklam, īpaši docker.hub.

Sīkāku informāciju par prasībām konkrētām OS un CI var atrast
vietnē dokumentācija.

Tagad ir pienācis laiks pievienot dažas rindas uz pom.xml.

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

Es izmantoju Testa konteineri versija 1.17.3, bet izmantojiet jaunāko.

Testi ar Postgres konteineru

Pirmais solis ir sagatavot konteinera gadījumu. To var izdarīt tieši testā, bet neatkarīga klase izskatās labāk.

public klase 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() {
   // neko nedara. Šī ir koplietojamā instance. Ļaujiet JVM apstrādāt šo operāciju.
 }
}

Testu sākumā mēs izveidosim instance of Postgres13TC. Šajā klasē var apstrādāt informāciju par mūsu konteineru. Vissvarīgākās ir datu bāzes savienojuma virknes un akreditācijas dati. Tagad ir pienācis laiks uzrakstīt ļoti vienkāršu testu.

@Testcontainers
klase 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());

   try (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();
   }
 }
}

Es šeit izmantoju JUnit 5. Anotācija @Testcontainers ir daļa no paplašinājumiem, kas kontrolē konteinerus testa vidē. Tie atrod visus laukus ar @Container anotāciju un attiecīgi start un stop konteinerus.

Testi ar Spring Boot

Kā jau iepriekš minēju, projektā izmantoju Spring Boot. Šajā gadījumā mums ir jāuzraksta nedaudz vairāk koda. Pirmais solis ir izveidot papildu konfigurācijas klasi.

@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()
   );
 }
}

Šī klase aizstāj esošās īpašības ar vērtībām no klases testa konteiners. Pirmās trīs īpašības ir standarta Spring īpašības. Nākamās piecas ir papildu, pielāgotas īpašības, kuras var izmantot, lai konfigurētu citus resursus un paplašinājumus, piemēram, liquibase:

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

Tagad ir pienācis laiks definēt vienkāršu integrācijas testu.

@SpringBootTest(webEnvironment = RANDOM_PORT)
@AutoConfigureTestDatabase(replace = NONE)
@ContextConfiguration(initializers = ContainerInit.class)
@Testcontainers
class 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);
 }
}

Šeit ir dažas papildu anotācijas.

• @SpringBootTest(webEnvironment = RANDOM_PORT) - atzīmē testu kā Spring Boot testu un uzsāk spring kontekstu.
• @AutoConfigureTestDatabase(aizstāt = NAV) - šīs anotācijas norāda, ka pavasara testa paplašinājumam nevajadzētu aizstāt postgres datubāzes konfigurāciju ar H2 atmiņas konfigurācijā.
• @ContextConfiguration(initializers = ContainerInit.class) - papildu pavasara konteksts
  konfigurācija, kurā mēs iestatām īpašības no Testa konteineri.
• @Testcontainers - kā minēts iepriekš, šī anotācija kontrolē konteinera dzīves ciklu.

Šajā piemērā es izmantoju reaktīvos repozitorijus, bet tas darbojas tāpat arī ar parastajiem JDBC un JPA repozitorijiem.

Tagad varam palaist šo testu. Ja tas ir pirmais palaidums, dzinējam ir jāvelk attēli no docker.hub. Tas var aizņemt brīdi. Pēc tam mēs redzēsim, ka ir palaisti divi konteineri. Viens no tiem ir postgres, bet otrs ir Testcontainers kontrolieris. Šis otrais konteiners pārvalda darbojošos konteinerus, un, pat ja JVM negaidīti apstājas, tas izslēdz konteinerus un sakopj vidi.

Apkoposim

Testa konteineri ir ļoti ērti lietojami rīki, kas palīdz mums izveidot integrācijas testus, kuros tiek izmantoti Docker konteineri. Tas mums sniedz lielāku elastību un palielina izstrādes ātrumu. Pareiza testu konfigurācijas iestatīšana samazina laiku, kas nepieciešams, lai uzņemtu jaunus izstrādātājus. Viņiem nav jākonfigurē visas atkarības, vienkārši jāpalaiž uzrakstītie testi ar izvēlētiem konfigurācijas failiem.