Bruke SpringJUnit4ClassRunner med Parameterized

1. Oversikt

I denne opplæringen vil vi se hvordan vi kan parameterisere en vårintegrasjonstest implementert i JUnit4 med en Parameterisert JUnit testløper.

2. SpringJUnit4ClassRunner

SpringJUnit4ClassRunner er en implementering av JUnit4 ClassRunner at innebærer vårens TestContextManager inn i en JUnit-test.

TestContextManager er inngangspunktet til våren TestContext rammeverk og styrer derfor tilgangen til våren ApplicationContext og avhengighetsinjeksjon i en JUnit-testklasse. Og dermed, SpringJUnit4ClassRunner gjør det mulig for utviklere å implementere integrasjonstester for vårkomponenter som kontrollere og arkiver.

For eksempel kan vi implementere en integrasjonstest for vår RestController:

@RunWith (SpringJUnit4ClassRunner.class) @WebAppConfiguration @ContextConfiguration (klasser = WebConfig.class) offentlig klasse RoleControllerIntegrationTest {@Autowired privat WebApplicationContext wac; private MockMvc mockMvc; privat statisk sluttstreng CONTENT_TYPE = "applikasjon / tekst; charset = ISO-8859-1"; @Før offentlige ugyldige oppsett () kaster unntak {this.mockMvc = MockMvcBuilders.webAppContextSetup (this.wac) .build (); } @Test offentlig ugyldig givenEmployeeNameJohnWhenInvokeRoleThenReturnAdmin () kaster unntak {this.mockMvc.perform (MockMvcRequestBuilders .get ("/ role / John")) .andDo (print ()) .andExpect (MockMvcResultMatchers.). andExpect (MockMvcResultMatchers.content (). contentType (CONTENT_TYPE)). andExpect (MockMvcResultMatchers.content (). string ("ADMIN")); }}

Som det kan sees fra testen, vår Kontroller aksepterer et brukernavn som baneparameter og returnerer brukerrollen deretter.

Nå, For å teste denne REST-tjenesten med et annet brukernavn / rollekombinasjon, må vi implementere en ny test:

@Test offentlig ugyldig givenEmployeeNameDoeWhenInvokeRoleThenReturnEmployee () kaster unntak {this.mockMvc.perform (MockMvcRequestBuilders .get ("/ role / Doe")) .andDo (print ()) .andExpect (MockMvcResultMatchers .Op. (MockMvcResultMatchers.content (). ContentType (CONTENT_TYPE)). Og Expect (MockMvcResultMatchers.content (). Streng ("MEDARBEIDER)); }

Dette kan raskt komme ut av hånden for tjenester der et stort antall inngangskombinasjoner er mulig.

For å unngå denne typen repetisjon i testklassene, la oss se hvordan du bruker Parameterisert for implementering av JUnit-tester som godtar flere innganger.

3. Bruke Parameterisert

3.1. Definere parametere

Parameterisert er en tilpasset JUnit-testløper som lar oss skrive en enkelt testtilfelle og få den til å kjøre mot flere inngangsparametere:

@RunWith (Parameterized.class) @WebAppConfiguration @ContextConfiguration (classes = WebConfig.class) public class RoleControllerParameterizedIntegrationTest {@Parameter (value = 0) public Strengnavn; @Parameter (verdi = 1) offentlig String rolle; @Parameters offentlige statiske data for samling () {Collection params = new ArrayList (); params.add (nytt objekt [] {"John", "ADMIN"}); params.add (nytt objekt [] {"Doe", "MEDARBEIDER}}; returparametre; } // ...}

Som vist ovenfor brukte vi @Parametere kommentar for å forberede inngangsparametrene som skal injiseres i JUnit-testen. Vi ga også kartleggingen av disse verdiene i @Parameter Enger Navn og rolle.

Men nå har vi et annet problem å løse - JUnit tillater ikke flere løpere i en JUnit-testklasse. Dette betyr vi kan ikke dra nytte av det SpringJUnit4ClassRunner å legge inn TestContextManagerinn i testklassen vår. Vi må finne en annen måte å legge inn TestContextManager.

Heldigvis gir Spring et par muligheter for å oppnå dette. Vi vil diskutere disse i de følgende avsnittene.

3.2. Initialiserer TestContextManager Manuelt

Det første alternativet er ganske enkelt, ettersom våren lar oss initialisere TestContextManager manuelt:

@RunWith (Parameterized.class) @WebAppConfiguration @ContextConfiguration (klasser = WebConfig.class) offentlig klasse RoleControllerParameterizedIntegrationTest {@Autowired private WebApplicationContext wac; private MockMvc mockMvc; privat TestContextManager testContextManager; @Før offentlig ugyldig oppsett () kaster Unntak {this.testContextManager = ny TestContextManager (getClass ()); this.testContextManager.prepareTestInstance (dette); this.mockMvc = MockMvcBuilders.webAppContextSetup (this.wac) .build (); } // ...}

Spesielt i dette eksemplet brukte vi Parameterisert løper i stedet for SpringJUnit4ClassRunner. Deretter initialiserte vi TestContextManager i oppsett () metode.

Nå kan vi implementere vår parameteriserte JUnit-test:

@Test offentlig ugyldighet givenEmployeeNameWhenInvokeRoleThenReturnRole () kaster unntak {this.mockMvc.perform (MockMvcRequestBuilders .get ("/ role /" + name)). AndDo (print ()). AndExpect (MockMvcResultMatchers.statk ().). andExpect (MockMvcResultMatchers.content (). contentType (CONTENT_TYPE)). andExpect (MockMvcResultMatchers.content (). streng (rolle)); }

JUnit vil utføre denne testsaken to ganger - en gang for hvert sett med innganger vi definerte ved hjelp av @Parametere kommentar.

3.3. SpringClassRule og SpringMethodRule

Som regel, det anbefales ikke å initialisere TestContextManager manuelt. I stedet anbefaler Spring å bruke SpringClassRule og SpringMethodRule.

SpringClassRule implementerer JUnit's Testregel - en alternativ måte å skrive prøvesaker på. TestRule kan brukes til å erstatte oppsett og opprydding som tidligere var gjort med @Før, @BeforeClass, @After, og @Etter timen metoder.

SpringClassRule innebærer funksjonalitet på klassenivå TestContextManager i en JUnit testklasse. Den initialiserer TestContextManager og påkaller oppsett og opprydding av våren TestContext. Derfor gir det avhengighetsinjeksjon og tilgang til ApplicationContext.

I tillegg til SpringClassRule, må vi også bruke SpringMethodRule. som gir forekomstenivå og metodenivåfunksjonalitet for TestContextManager.

SpringMethodRule er ansvarlig for utarbeidelsen av testmetodene. Den sjekker også for testsaker som er merket for å hoppe over, og hindrer dem i å kjøre.

La oss se hvordan du bruker denne tilnærmingen i testklassen vår:

@RunWith (Parameterized.class) @WebAppConfiguration @ContextConfiguration (classes = WebConfig.class) public class RoleControllerParameterizedClassRuleIntegrationTest {@ClassRule public static final SpringClassRule scr = new SpringClassRule (); @Rule public final SpringMethodRule smr = new SpringMethodRule (); @Før offentlige ugyldige oppsett () kaster unntak {this.mockMvc = MockMvcBuilders.webAppContextSetup (this.wac) .build (); } // ...}

4. Konklusjon

I denne artikkelen diskuterte vi to måter å implementere vårintegrasjonstester på Parameterisert testløper i stedet for SpringJUnit4ClassRunner. Vi så hvordan vi kunne initialisere TestContextManager manuelt, og vi så et eksempel med SpringClassRule med SpringMethodRule, tilnærmingen anbefalt av våren.

Selv om vi bare diskuterte Parameterisert løper i denne artikkelen, vi kan faktisk bruke en av disse tilnærmingene med en hvilken som helst JUnit-løper å skrive vårintegrasjonstester.

Som vanlig er all eksempelkoden tilgjengelig på GitHub.


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