Introduksjon til JUnitParams

1. Oversikt

I denne artikkelen vil vi utforske JUnitParams biblioteket og dets bruksområder. Enkelt sagt, dette biblioteket gir enkel parameterisering av testmetoder i JUnit tester.

Det er situasjoner der det eneste som skifter mellom flere tester er parametrene. JUnit selv har en parameteriseringsstøtte, og JUnitParams forbedrer den funksjonaliteten betydelig.

2. Maven avhengighet

Å bruke JUnitParams i prosjektet vårt, må vi legge det til vårt pom.xml:

 pl.pragmatikere JUnitParams 1.1.0 

Den siste versjonen av biblioteket finner du her.

3. Test Scenario

La oss lage en klasse som gjør det sikkert å legge til to heltall. Dette skal komme tilbake Heltall.MAX_VALUE hvis det renner over, og Heltall.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. Konstruere en enkel testmetode

Vi må teste metodeimplementering for forskjellige kombinasjoner av inngangsverdier, for å sikre at implementeringen gjelder for alle mulige scenarier. JUnitParams gir mer enn en måte å oppnå den parameteriserte testopprettingen på.

La oss ta den grunnleggende tilnærmingen med en minimal mengde koding og se hvordan det gjøres. Etter det kan vi se hva de andre mulige måtene å implementere testscenariene ved hjelp av 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)); }}

La oss nå se hvordan denne testklassen skiller seg fra en vanlig JUnit testklasse.

Det første vi legger merke til er at det er enannen testløper i klassekommentar - JUnitParamsRunner.

Når vi går videre til testmetoden, ser vi at testmetoden er merket med @Parametere kommentar med en rekke inngangsparametere. Det indikerer forskjellige testscenarier som vil bli brukt til å teste servicemetoden vår.

Hvis vi kjører testen med Maven, får vi se det vi kjører fire testsaker og ikke en eneste. Utgangen vil være lik følgende:

-------------------------------------------------- ----- TESTER -------------------------------------------- ----------- Kjører com.baeldung.junitparams.SafeAdditionUtilTest Tester kjørt: 4, feil: 0, feil: 0, hoppet over: 0, forløpt tid: 0,068 sek - i com.baeldung.junitparams.SafeAdditionUtilTest Resultater: Testkjøring: 4, Feil: 0, Feil: 0, Hoppet over: 0

5. Ulike typer parametrisering av testmetoder

Å gi testparametere direkte i kommentaren er absolutt ikke den mest lesbare måten hvis vi har mange mulige scenarier som må testes. JUnitParams tilbyr et sett med forskjellige tilnærminger vi kan bruke til å lage parametriserte tester:

  • Direkte i @Parametere kommentar (brukt i eksemplet ovenfor)
  • Ved hjelp av en navngitt testmetode definert i kommentaren
  • Ved hjelp av en metode kartlagt av testmetodens navn
  • En navngitt testklasse definert i kommentaren
  • Bruke en CSV-fil

La oss utforske tilnærmingene en etter en.

5.1. Direkte i @Parametere Kommentar

Vi har allerede brukt denne tilnærmingen i eksemplet vi prøvde. Det vi må huske på er at vi skal tilby en rekke parameterstrenger. Innenfor parameterstrengen er hver parameter skilt med komma.

For eksempel vil matrisen være i form av { “1, 2, 3”, “-10, 30, 20”} og ett sett med parametere er representert som “1, 2, 3”.

Begrensningen med denne tilnærmingen er at vi bare kan levere primitiver og Strings som testparametere. Det er ikke mulig å sende inn objekter som testmetodeparametere også.

5.2. Parameter Metode

Vi kan tilby testmetodeparametrene ved hjelp av en annen metode i klassen. La oss 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 Object [] parametersToTestAdd () {return new Object [] {new Object [] {1, 2, 3}, new Object [] {-10, 30, 20}, new Object [] {Integer.MAX_VALUE, 2 , Integer.MAX_VALUE}, nytt objekt [] {Integer.MIN_VALUE, -8, Integer.MIN_VALUE}}; }

Testmetoden kommenteres om metoden parametersToAdd (), og den henter parametrene ved å kjøre den refererte metoden.

Spesifikasjonen for leverandørmetoden skal returnere en rekke Gjenstands som et resultat. Hvis en metode med gitt navn ikke er tilgjengelig, mislykkes testsaken med feilen:

java.lang.RuntimeException: Fant ikke metoden: bogusMethodName så ingen parametre ble brukt.

5.3. Metode kartlagt av testmetodens navn

Hvis vi ikke spesifiserer noe i @Parametere kommentar, JUnitParams prøver å laste inn en testdataleverandørmetode basert på testmetodens navn. Metodenavnet er konstruert som “ParametersFor” +:

@Test @Parameters offentlig ugyldig nårWithnoParam_thenLoadByNameSafeAdd (int a, int b, int expectedValue) {assertEquals (expectedValue, serviceUnderTest.safeAdd (a, b)); } private Object [] parametersForWhenWithnoParam_thenLoadByNameSafe () {return new Object [] {new Object [] {1, 2, 3}, new Object [] {-10, 30, 20}, new Object [] {Integer.MAX_VALUE, 2 , Integer.MAX_VALUE}, nytt objekt [] {Integer.MIN_VALUE, -8, Integer.MIN_VALUE}}; }

I eksemplet ovenfor er navnet på testmetoden whenWithnoParam_shouldLoadByNameAbdSafeAdd ().

Derfor når testmetoden kjøres, ser den etter en dataleverandørmetode med navnet parametersForWhenWithnoParam_shouldLoadByNameAbdSafeAdd ().

Siden den metoden eksisterer, vil den laste inn data fra den og kjøre testen. Hvis det ikke er noen slik metode som samsvarer med det nødvendige navnet, mislykkes testen som i eksemplet ovenfor.

5.4. Navngitt testklasse definert i kommentaren

I likhet med måten vi refererte til en dataleverandørmetode i et tidligere eksempel, kan vi referere til en egen klasse for å gi dataene til testen vår:

@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}, nytt objekt [] {-5, -10, -15}}; } offentlig statisk objekt [] provideEdgeCaseData () {returner nytt objekt [] {nytt objekt [] {Integer.MAX_VALUE, 2, Integer.MAX_VALUE}, nytt objekt [] {Integer.MIN_VALUE, -2, Integer.MIN_VALUE},} ; }}

Vi kan ha et hvilket som helst antall leverandører av testdata i en klasse gitt at metodenavnet starter med "gi". I så fall velger utføreren disse metodene og returnerer dataene.

Hvis ingen klassemetoder tilfredsstiller dette kravet, selv om disse metodene returnerer en rekke Gjenstands, disse metodene vil bli ignorert.

5.5. Bruke en CSV-fil

Vi kan bruke en ekstern CSV-fil til å laste inn testdataene. Dette hjelper hvis antallet mulige testsaker er ganske betydelig, eller hvis testsaker ofte endres. Endringene kan gjøres uten å påvirke testkoden.

La oss si at vi har en CSV-fil med testparametere som JunitParamsTestParameters.csv:

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

La oss nå se hvordan denne filen kan brukes til å laste inn testparametere 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 begrensning i denne tilnærmingen er at det ikke er mulig å passere komplekse objekter. Bare primitiver og Strings er gyldige.

6. Konklusjon

I denne veiledningen så vi på hvordan vi kan bruke funksjonene til JUnitParams i et nøtteskall.

Vi dekket også forskjellige tilnærminger biblioteket gir oss for å levere testparametere til testmetodene våre - langt utover hva JUnit selv kan gjøre.

Som alltid kan kildekoden bli funnet på GitHub.


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