Introduktion til JUnitParams

1. Oversigt

I denne artikel undersøger vi JUnitParams bibliotek og dets anvendelser. Kort sagt, dette bibliotek giver nem parametrering af testmetoder i JUnit test.

Der er situationer, hvor det eneste, der skifter mellem flere tests, er parametrene. JUnit selv har en parameteriseringsunderstøttelse, og JUnitParams forbedrer denne funktionalitet markant.

2. Maven-afhængighed

At bruge JUnitParams i vores projekt skal vi tilføje det til vores pom.xml:

 pl.pragmatikere JUnitParams 1.1.0 

Den seneste version af biblioteket kan findes her.

3. Test scenarie

Lad os oprette en klasse, der udfører en sikker tilføjelse af to heltal. Dette skal vende tilbage Heltal.MAX_VALUE hvis det løber over, og Heltal.MIN_VALUE hvis det strømmer under:

offentlig klasse SafeAdditionUtil {public int safeAdd (int a, int b) {long result = ((long) a) + b; hvis (resultat> Integer.MAX_VALUE) {return Integer.MAX_VALUE; } ellers hvis (resultat <Integer.MIN_VALUE) {return Integer.MIN_VALUE; } returner (int) resultat; }}

4. Konstruktion af en simpel testmetode

Vi bliver nødt til at teste metodeimplementering for forskellige kombinationer af inputværdier for at sikre, at implementeringen gælder for alle mulige scenarier. JUnitParams giver mere end en måde at opnå den parametriserede testoprettelse på.

Lad os tage den grundlæggende tilgang med en minimal mængde kodning og se, hvordan det gøres. Derefter kan vi se, hvad de andre mulige måder at implementere testscenarierne ved hjælp af JUnitParams er:

@RunWith (JUnitParamsRunner.class) offentlig klasse SafeAdditionUtilTest {private SafeAdditionUtil serviceUnderTest = ny SafeAdditionUtil (); @Test @Parameters ({"1, 2, 3", "-10, 30, 20", "15, -5, 10", "-5, -10, -15"}) offentlig ugyldig nårWithAnnotationProvidedParams_thenSafeAdd (int a , int b, int expectedValue) {assertEquals (expectValue, serviceUnderTest.safeAdd (a, b)); }}

Lad os nu se, hvordan denne testklasse adskiller sig fra en almindelig JUnit test klasse.

Den første ting, vi bemærker, er det der er enforskellige testløbere i klassebemærkningen - JUnitParamsRunner.

Når vi går videre til testmetoden, ser vi, at testmetoden er kommenteret @Parameters kommentar med en række inputparametre. Det angiver forskellige testscenarier, som vil blive brugt til at teste vores servicemetode.

Hvis vi kører testen ved hjælp af Maven, ser vi det vi kører fire testsager og ikke en eneste. Outputtet svarer til følgende:

-------------------------------------------------- ----- TESTER -------------------------------------------- ----------- Kører com.baeldung.junitparams.SafeAdditionUtilTest Testkørsel: 4, Fejl: 0, Fejl: 0, springet over: 0, forløbet tid: 0,068 sek - i com.baeldung.junitparams.SafeAdditionUtilTest Resultater: Testkørsel: 4, Fejl: 0, Fejl: 0, Springet over: 0

5. Forskellige typer parametrisering af testmetoder

At levere testparametre direkte i kommentaren er bestemt ikke den mest læsbare måde, hvis vi har mange mulige scenarier, der skal testes. JUnitParams tilbyder et sæt forskellige tilgange, vi kan bruge til at oprette de parametriserede tests:

  • Direkte i @Parameters kommentar (brugt i eksemplet ovenfor)
  • Brug af en navngivet testmetode, der er defineret i kommentaren
  • Ved hjælp af en metode kortlagt af testmetodens navn
  • En navngivet testklasse defineret i kommentaren
  • Brug af en CSV-fil

Lad os udforske fremgangsmåderne en efter en.

5.1. Direkte i @Parameters Kommentar

Vi har allerede brugt denne tilgang i eksemplet, vi prøvede. Det, vi skal huske på, er, at vi skal levere en række parameterstrenge. Inden for parameterstrengen er hver parameter adskilt med et komma.

For eksempel ville arrayet være i form af { “1, 2, 3”, “-10, 30, 20”} og et sæt parametre er repræsenteret som “1, 2, 3”.

Begrænsningen ved denne tilgang er, at vi kun kan levere primitive og Snors som testparametre. Det er ikke muligt at indsende objekter også som testmetodeparametre.

5.2. Parameter Metode

Vi kan levere testmetodeparametrene ved hjælp af en anden metode inden for klassen. Lad os se et eksempel først:

@Test @Parameters (method = "parametersToTestAdd") offentlig ugyldig nårWithNamedMethod_thenSafeAdd (int a, int b, int expectedValue) {assertEquals (expectValue, serviceUnderTest.safeAdd (a, b)); } private Objekt [] parametersToTestAdd () {returner nyt Objekt [] {nyt Objekt [] {1, 2, 3}, nyt Objekt [] {-10, 30, 20}, nyt Objekt [] {Heltal.MAX_VALUE, 2 , Integer.MAX_VALUE}, nyt objekt [] {Integer.MIN_VALUE, -8, Integer.MIN_VALUE}}; }

Testmetoden kommenteres om metoden parametersToAdd (), og det henter parametrene ved at køre den refererede metode.

Specifikationen af ​​udbydermetoden skal returnere en matrix af Objekts som et resultat. Hvis en metode med det givne navn ikke er tilgængelig, mislykkes testsagen med fejlen:

java.lang.RuntimeException: Kunne ikke finde metode: bogusMethodName, så der blev ikke brugt parametre.

5.3. Metode kortlagt med testmetodens navn

Hvis vi ikke angiver noget i @Parameters kommentar, JUnitParams forsøger at indlæse en testdataudbydermetode baseret på navnet på testmetoden. Metodenavnet er konstrueret som “ParametersFor” +:

@Test @Parameters er ugyldige nårWithnoParam_thenLoadByNameSafeAdd (int a, int b, int expectedValue) {assertEquals (expectValue, serviceUnderTest.safeAdd (a, b)); } private Objekt [] parametreForWhenWithnoParam_thenLoadByNameSafe () {returner nyt Objekt [] {nyt Objekt [] {1, 2, 3}, nyt Objekt [] {-10, 30, 20}, nyt Objekt [] {Heltal.MAX_VALUE, 2 , Integer.MAX_VALUE}, nyt objekt [] {Integer.MIN_VALUE, -8, Integer.MIN_VALUE}}; }

I ovenstående eksempel er testmetodens navn whenWithnoParam_shouldLoadByNameAbdSafeAdd ().

Derfor, når testmetoden udføres, ser den efter en dataudbydermetode med navnet parametersForWhenWithnoParam_shouldLoadByNameAbdSafeAdd ().

Da denne metode findes, indlæser den data fra den og kører testen. Hvis der ikke findes en sådan metode, der matcher det krævede navn, mislykkes testen som i ovenstående eksempel.

5.4. Navngivet testklasse defineret inden for kommentaren

I lighed med den måde, vi henviste til en dataudbydermetode i et tidligere eksempel, kan vi henvise til en separat klasse for at levere dataene til vores test:

@Test @Parameters (kilde = TestDataProvider.class) offentlig ugyldig nårWithNamedClass_thenSafeAdd (int a, int b, int expectedValue) {assertEquals (expectValue, serviceUnderTest.safeAdd (a, b)); } offentlig klasse TestDataProvider {public static Object [] provideBasicData () {return new Object [] {new Object [] {1, 2, 3}, new Object [] {-10, 30, 20}, new Object [] { 15, -5, 10}, nyt objekt [] {-5, -10, -15}}; } offentligt statisk objekt [] giveEdgeCaseData () {returner nyt objekt [] {nyt objekt [] {Integer.MAX_VALUE, 2, Integer.MAX_VALUE}, nyt objekt [] {Integer.MIN_VALUE, -2, Integer.MIN_VALUE},} ; }}

Vi kan have et hvilket som helst antal testdataleverandører i en klasse, forudsat at metodens navn starter med "give". I så fald vælger eksekutoren disse metoder og returnerer dataene.

Hvis ingen klassemetoder opfylder dette krav, selvom disse metoder returnerer en matrix af Objekts, disse metoder vil blive ignoreret.

5.5. Brug af en CSV-fil

Vi kan bruge en ekstern CSV-fil til at indlæse testdata. Dette hjælper, hvis antallet af mulige testsager er ret signifikant, eller hvis testsager ofte ændres. Ændringerne kan udføres uden at påvirke testkoden.

Lad os sige, at vi har en CSV-fil med testparametre som JunitParamsTestParameters.csv:

1,2,3 -10, 30, 20 15, -5, 10 -5, -10, -15

Lad os nu se hvordan denne fil kan bruges til at indlæse testparametre i testmetoden:

@Test @FileParameters ("src / test / resources / JunitParamsTestParameters.csv") offentlig ugyldig nårWithCsvFile_thenSafeAdd (int a, int b, int expectedValue) {assertEquals (expectValue, serviceUnderTest.safeAdd (a, b)) }

En begrænsning ved denne tilgang er, at det ikke er muligt at passere komplekse objekter. Kun primitiver og Snors er gyldige.

6. Konklusion

I denne vejledning så vi på, hvordan vi kan udnytte funktionerne i JUnitParams i en nøddeskal.

Vi dækkede også forskellige tilgange, som biblioteket giver os til at levere testparametre til vores testmetoder - langt ud over hvad JUnit selv kan gøre.

Som altid kan kildekoden findes på GitHub.


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