Test af Spring Boot @ConfigurationProperties

1. Oversigt

I vores tidligere guide til @ConfigurationProperties, vi lærte at konfigurere og bruge @ConfigurationProperties kommentar med Spring Boot til arbejde med ekstern konfiguration.

I denne vejledning vi viser, hvordan man tester konfigurationsklasser, der er afhængige af @ConfigurationProperties kommentar for at sikre, at vores konfigurationsdata er indlæst og bundet korrekt til deres tilsvarende felter.

2. Afhængigheder

I vores Maven-projekt bruger vi spring-boot-starter og spring-boot-starter-test afhængigheder for at aktivere henholdsvis kernefjeder-API og Spring's test-API:

 org.springframework.boot spring-boot-starter-parent 2.2.2.RELEASE org.springframework.boot spring-boot-starter org.springframework.boot spring-boot-starter-test test 

Lad os også konfigurere vores projekt med afhængighed af bønnevalidering, da vi bruger dem senere:

  org.hibernate dvale-validator javax.el javax.el-api 3.0.0 org.glassfish.web javax.el 2.2.6 

3. Egenskaber, der binder til brugerdefinerede POJO'er

Når du arbejder med ekstern konfiguration, vi opretter typisk POJO'er, der indeholder felter, der svarer til de matchende konfigurationsegenskaber. Som vi allerede ved, binder Spring derefter automatisk konfigurationsegenskaberne til de Java-klasser, vi opretter.

Til at begynde med antager vi, at vi har en vis serverkonfiguration i en egenskabsfil, vi kalder på src / test / resources / server-config-test.properties:

server.address.ip = 192.168.0.1 server.resources_path.imgs = / root / imgs

Lad os nu definere en simpel konfigurationsklasse svarende til den tidligere egenskabsfil:

@Configuration @ConfigurationProperties (præfiks = "server") offentlig klasse ServerConfig {privat adresse adresse; private kortressourcer; vej; // getters og setters}

og også det tilsvarende Adresse type:

offentlig klasse Adresse {privat streng ip; // getters og setters}

Lad os endelig injicere ServerConfig POJO i vores testklasse og validere, at alle dens felter er indstillet korrekt:

@ExtendWith (SpringExtension.class) @EnableConfigurationProperties (value = ServerConfig.class) @TestPropertySource ("classpath: server-config-test.properties") public class BindingPropertiesToUserDefinedPOJOUnitTest {@Autowig serverConfigureret serverConfigert @Test ugyldigt givenUserDefinedPOJO_whenBindingPropertiesFile_thenAllFieldsAreSet () {assertEquals ("192.168.0.1", serverConfig.getAddress (). GetIp ()); Kort expectResourcesPath = ny HashMap (); expectResourcesPath.put ("imgs", "/ root / imgs"); assertEquals (expectResourcesPath, serverConfig.getResourcesPath ()); }}

I denne test har vi brugt følgende kommentarer:

  • @ExtendWith - integrerer Spring's TestContext-ramme med JUnit5
  • @EnableConfigurationProperties - muliggør support til @ConfigurationProperties bønner (i dette tilfælde ServerConfig bønne)
  • @TestPropertySource - angiver en testfil, der tilsidesætter standard application.properties fil

4. @ConfigurationProperties@Bønne Metoder

En anden måde at oprette konfigurationsbønner på er ved hjælp af @ConfigurationProperties kommentar til @Bønne metoder.

For eksempel følgende getDefaultConfigs () metode skaber en ServerConfig konfigurationsbønne:

@Configuration public class ServerConfigFactory {@Bean (name = "default_bean") @ConfigurationProperties (prefix = "server.default") public ServerConfig getDefaultConfigs () {returner ny ServerConfig (); }}

Som vi kan se, er vi i stand til at konfigurere ServerConfig eksempel ved hjælp af @ConfigurationProperties på den getDefaultConfigs () uden at skulle redigere ServerConfig klassen selv. Dette kan være særligt nyttigt, når du arbejder med en ekstern tredjepartsklasse, der har begrænset adgang.

Lad os derefter definere en prøve ekstern egenskab:

server.default.address.ip = 192.168.0.2

Endelig at fortælle foråret at bruge ServerConfigFactory klasse ved indlæsning af ApplicationContext (lav derfor vores konfigurationsbønne), vi tilføjer @ContextConfiguration kommentar til testklassen:

@ExtendWith (SpringExtension.class) @EnableConfigurationProperties (værdi = ServerConfig.class) @ContextConfiguration (klasser = ServerConfigFactory.class) @TestPropertySource ("classpath: server-config-test.properties") offentlig klasse BindingProperties "QTestMetoden" default_bean ") privat ServerConfig serverConfig; @Test ugyldigt givenBeanAnnotatedMethod_whenBindingProperties_thenAllFieldsAreSet () {assertEquals ("192.168.0.2", serverConfig.getAddress (). GetIp ()); // andre påstande ...}}

5. Validering af egenskaber

For at aktivere bønnevalidering i Spring Boot, vi skal kommentere topklassen med @Valideret. Derefter tilføjer vi det krævede javax.validation begrænsninger:

@Configuration @ConfigurationProperties (prefix = "validate") @Validated public class MailServer {@NotNull @NotEmpty Map Map PropertiesMap; @Valid privat MailConfig mailConfig = ny MailConfig (); // getters og setters}

Tilsvarende er MailConfig klasse har også nogle begrænsninger:

offentlig klasse MailConfig {@NotBlank @Email privat strengadresse; // getters og setters}

Ved at levere et gyldigt datasæt:

validate.propertiesMap.first = prop1 validate.propertiesMap.second = prop2 [e-mail-beskyttet]

applikationen starter normalt, og vores enhedstest vil bestå:

@ExtendWith (SpringExtension.class) @EnableConfigurationProperties (value = MailServer.class) @TestPropertySource ("classpath: property-validation-test.properties") public class PropertyValidationUnitTest {@Autowired private MailServer mailServer; privat statisk Validator propertyValidator; @BeforeAll offentlig statisk ugyldig opsætning () {propertyValidator = Validation.buildDefaultValidatorFactory (). GetValidator (); } @Test ugyldig nårBindingPropertiesToValidatedBeans_thenConstrainsAreChecked () {assertEquals (0, propertyValidator.validate (mailServer.getPropertiesMap ()). Størrelse ()); assertEquals (0, propertyValidator.validate (mailServer.getMailConfig ()). størrelse ()); }}

På den anden side, hvis vi bruger ugyldige egenskaber, kaster Spring et IllegalStateException ved opstart.

For eksempel ved hjælp af en af ​​disse ugyldige konfigurationer:

validate.propertiesMap.second = validate.mail_config.address = bruger1.test

vil medføre, at vores ansøgning mislykkes med denne fejlmeddelelse:

Ejendom: validate.propertiesMap [sekund] Værdi: Årsag: må ikke være tomt Ejendom: validate.mailConfig.address Værdi: bruger1.test Årsag: skal være en velformet e-mail-adresse

Læg mærke til det vi har brugt @Gyldig på den mailConfig felt for at sikre, at MailConfig begrænsninger kontrolleres, selvom validate.mailConfig.adresse var ikke defineret. Ellers ville foråret sætte sig mailConfig til nul og start applikationen normalt.

6. Konvertering af egenskaber

Spring Boot egenskaber konvertering giver os mulighed for at konvertere nogle egenskaber til bestemte typer.

I dette afsnit starter vi med at teste konfigurationsklasser, der bruger Spring's indbyggede konvertering. Derefter tester vi en brugerdefineret konverter, som vi selv opretter.

6.1. Spring Boot's standardkonvertering

Lad os overveje følgende datastørrelses- og varighedsegenskaber:

# datastørrelser convert.upload_speed = 500Mm convert.download_speed = 10 # varighed convert.backup_day = 1d convert.backup_hour = 8

Spring Boot binder automatisk disse egenskaber til matchningen DataSize og Varighed felter defineret i PropertyConversion konfigurationsklasse:

@Configuration @ConfigurationProperties (præfiks = "konverter") offentlig klasse PropertyConversion {private DataSize uploadSpeed; @DataSizeUnit (DataUnit.GIGABYTES) privat DataSize downloadSpeed; privat varighed backupDag; @DurationUnit (ChronoUnit.HOURS) privat Varighed backupHour; // getters og setters}

Lad os nu kontrollere konverteringsresultaterne:

@ExtendWith (SpringExtension.class) @EnableConfigurationProperties (værdi = PropertyConversion.class) @ContextConfiguration (klasser = CustomCredentialsConverter.class) @TestPropertySource ("classpath: spring-conversion-test.properties") offentlig klasse SpringPropertiesConversionConvert @Test ugyldig nårUsingSpringDefaultSizeConversion_thenDataSizeObjectIsSet () {assertEquals (DataSize.ofMegabytes (500), propertyConversion.getUploadSpeed ​​()); assertEquals (DataSize.ofGigabytes (10), propertyConversion.getDownloadSpeed ​​()); } @Test ugyldigt nårUsingSpringDefaultDurationConversion_thenDurationObjectIsSet () {assertEquals (Duration.ofDays (1), propertyConversion.getBackupDay ()); assertEquals (Duration.ofHours (8), propertyConversion.getBackupHour ()); }}

6.2. Brugerdefinerede konvertere

Lad os forestille os, at vi vil konvertere konvertere.oplysninger ejendom:

convert.credentials = bruger, 123

i det følgende Legitimationsoplysninger klasse:

Public class Credentials {private String username; privat strengadgangskode; // getters og setters}

For at opnå dette kan vi implementere en brugerdefineret konverter:

@Component @ConfigurationPropertiesBinding offentlig klasse CustomCredentialsConverter implementerer Converter {@Override public Credentials convert (String source) {String [] data = source.split (","); returnere nye legitimationsoplysninger (data [0], data [1]); }}

Lad os endelig tilføje en Legitimationsoplysninger felt til PropertyConversion klasse:

offentlig klasse PropertyConversion {private legitimationsoplysninger legitimationsoplysninger; // ...}

I vores SpringPropertiesConversionUnitTest testklasse, skal vi også tilføje @ContextConfiguration at registrere den tilpassede konverter i Spring's sammenhæng:

// andre kommentarer @ContextConfiguration (klasser = CustomCredentialsConverter.class) offentlig klasse SpringPropertiesConversionUnitTest {// ... @Test ugyldig nårRegisteringCustomCredentialsConverter_thenCredentialsAreParsed () {assertEquals ("bruger", propertyConversion.getCred.). assertEquals ("123", propertyConversion.getCredentials (). getPassword ()); }}

Som de foregående påstande viser, Spring har brugt vores brugerdefinerede konverter til at analysere konvertere.oplysninger ejendom til en Legitimationsoplysninger eksempel.

7. Binding af YAML-dokumenter

For hierarkiske konfigurationsdata kan YAML-konfiguration være mere praktisk. Derudover understøtter YAML at definere flere profiler i det samme dokument.

Det følgende ansøgning.yml placeret under src / test / ressourcer / definerer en "test" profil for ServerConfig klasse:

forår: profiler: test server: adresse: ip: 192.168.0.4 ressourcer_sti: imgs: / etc / test / imgs --- # andre profiler

Som et resultat vil følgende test bestå:

@ExtendWith (SpringExtension.class) @ContextConfiguration (initializers = ConfigFileApplicationContextInitializer.class) @EnableConfigurationProperties (value = ServerConfig.class) @ActiveProfiles ("test") public class BindingYMLPropertiesUnitow Server = @ActiveProfiles ("test"). @Test ugyldigt nårBindingYMLConfigFile_thenAllFieldsAreSet () {assertEquals ("192.168.0.4", serverConfig.getAddress (). GetIp ()); // andre påstande ...}}

Et par noter vedrørende de anvendte kommentarer:

  • @ContextConfiguration (initialisatorer = ConfigFileApplicationContextInitializer.class) - indlæser ansøgning.yml fil
  • @ActiveProfiles (“test”) - specificerer, at "test" -profilen vil blive brugt under denne test

Lad os endelig huske det ingen af ​​dem @ProperySource heller ikke @TestProperySource support indlæsning .yml filer. Derfor skal vi altid placere vores YAML-konfigurationer inden for ansøgning.yml fil.

8. Tilsidesættelse @ConfigurationProperties Konfigurationer

Nogle gange vil vi måske tilsidesætte konfigurationsegenskaber, der er indlæst af @ConfigurationProperties med et andet datasæt, især ved test.

Som vi har vist i tidligere eksempler, kan vi bruge @TestPropertySource ("sti_til_ny_data_sæt") for at erstatte hele den oprindelige konfiguration (under / src / main / ressourcer) med en ny.

Alternativt kunne vi selektivt erstatte nogle af de originale egenskaber ved hjælp af ejendomme attribut for @TestPropertySource såvel.

Antag, at vi vil tilsidesætte det tidligere definerede validate.mail_config.address ejendom med en anden værdi. Alt hvad vi skal gøre er at kommentere vores testklasse med @TestPropertySource og tildel derefter en ny værdi til den samme ejendom via ejendomme liste:

@TestPropertySource (egenskaber = {"[e-mailbeskyttet]"})

Derfor vil Spring bruge den nyligt definerede værdi:

assertEquals ("[email protected]", mailServer.getMailConfig (). getAddress ());

9. Konklusion

I denne vejledning har vi set, hvordan man tester forskellige typer konfigurationsklasser, der bruger @ConfigurationProperties kommentar, der skal indlæses .ejendomme og .yml konfigurationsfiler.

Som normalt er kildekoden til denne artikel tilgængelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found