Påstander i JUnit 4 og JUnit 5

1. Introduksjon

I denne artikkelen skal vi utforske påstandene som er tilgjengelige innen JUnit i detalj.

Etter overgangen fra JUnit 4 til JUnit 5 og A Guide to JUnit 5-artikler, går vi nå inn på detaljer om de forskjellige påstandene som er tilgjengelige i JUnit 4 og JUnit 5.

Vi vil også fremheve forbedringene som er gjort med påstandene med JUnit 5.

2. Påstander

Påstander er verktøymetoder for å støtte hevdende forhold i tester; disse metodene er tilgjengelige gjennom Påstå klasse, i JUnit 4, og Påstander en, i JUnit 5.

For å øke testens lesbarhet og påstandene, anbefales det alltid å import statisk den respektive klassen. På denne måten kan vi henvise direkte til selve påstandsmetoden uten å representere klassen som et prefiks.

La oss begynne å utforske påstandene som er tilgjengelige med JUnit 4.

3. Påstander i JUnit 4

I denne versjonen av biblioteket er påstander tilgjengelige for alle primitive typer, Gjenstander, og arrays (enten av primitiver eller Objekter).

Parameterrekkefølgen, innenfor påstanden, er den forventede verdien etterfulgt av den faktiske verdien; valgfritt kan den første parameteren være a String melding som representerer meldingsutgangen til den evaluerte tilstanden.

Det er bare en litt annerledes i hvordan er definert hevder det påstander, men vi vil dekke det senere.

La oss starte med hevderEquals en.

3.1. hevderEquals

De hevderEquals påstand bekrefter at forventede og faktiske verdier er like:

@Test offentlig ugyldig nårAssertingEquality_thenEqual () {Streng forventet = "Baeldung"; String actual = "Baeldung"; assertEquals (forventet, faktisk); }

Det er også mulig å spesifisere en melding som skal vises når påstanden mislykkes:

assertEquals ("feil - strenger er ikke like", forventet, faktisk);

3.2. assertArrayEquals

Hvis vi vil hevde at to matriser er like, kan vi bruke assertArrayEquals:

@Test offentlig ugyldig nårAssertingArraysEquality_thenEqual () {char [] expected = {'J', 'u', 'n', 'i', 't'}; char [] actual = "Junit" .toCharArray (); assertArrayEquals (forventet, faktisk); }

Hvis begge matriser er nullvil påstanden betrakte dem like:

@Test offentlig ugyldighet gittNullArrays_whenAssertingArraysEquality_thenEqual () {int [] forventet = null; int [] faktisk = null; assertArrayEquals (forventet, faktisk); }

3.3. hevderNotNull og hevder Null

Når vi vil teste om et objekt er det null vi kan bruke hevder Null påstand:

@Test offentlig ugyldig nårAssertingNull_thenTrue () {Objektbil = null; assertNull ("Bilen skal være null", bil); }

På den motsatte måten, hvis vi vil hevde at et objekt ikke skal være null, kan vi bruke assertNotNull påstand.

3.4. assertNotSame og hevderSamme

Med assertNotSame, er det mulig å verifisere om to variabler ikke refererer til det samme objektet:

@Test offentlig ugyldig nårAssertingNotSameObject_thenDifferent () {Object cat = new Object (); Objekthund = nytt objekt (); assertNotSame (katt, hund); }

Ellers, når vi ønsker å bekrefte at to variabler refererer til det samme objektet, kan vi bruke hevderSamme påstand.

3.5. hevder sant og hevder falske

I tilfelle vi ønsker å bekrefte at en viss tilstand er ekte eller falsk, kan vi henholdsvis bruke hevder sant påstand eller hevder falske en:

@Test offentlig ugyldig nårAssertingConditions_thenVerified () {assertTrue ("5 er større enn 4", 5> 4); assertFalse ("5 er ikke større enn 6", 5> 6); }

3.6. mislykkes

De mislykkes påstand mislykkes en test som kaster en AssertionFailedError. Den kan brukes til å verifisere at et faktisk unntak blir kastet, eller når vi ønsker å gjøre en test som mislykkes under utviklingen.

La oss se hvordan vi kan bruke det i det første scenariet:

@Test offentlig ugyldig nårCheckingExceptionMessage_thenEqual () {prøv {methodThatShouldThrowException (); fail ("Unntak ikke kastet"); } fange (UnsupportedOperationException e) {assertEquals ("Operation Not Supported", e.getMessage ()); }}

3.7. hevder det

De hevder det påstand er den eneste i JUnit 4 som har omvendt rekkefølge av parametrene sammenlignet med de andre påstandene.

I dette tilfellet har påstanden en valgfri feilmelding, den faktiske verdien og en Matcher gjenstand.

La oss se hvordan vi kan bruke denne påstanden for å sjekke om en matrise inneholder bestemte verdier:

@Test offentlig ugyldig testAssertThatHasItems () {assertThat (Arrays.asList ("Java", "Kotlin", "Scala"), hasItems ("Java", "Kotlin")); } 

Ytterligere informasjon om kraftig bruk av hevder det påstand med Matcher objekt, er tilgjengelig på Testing with Hamcrest.

4. JUnit 5 påstander

JUnit 5 beholdt mange av påstandsmetodene til JUnit 4, mens det ble lagt til få nye som benytter seg av Java 8-støtten.

Også i denne versjonen av biblioteket er påstander tilgjengelige for alle primitive typer, Gjenstander, og matriser (enten av primitiver eller gjenstander).

Rekkefølgen på parameterne for påstandene endret seg, og flyttet parameteren for utdatameldingen som den siste parameteren. Takket være støtten til Java 8 kan utgangsmeldingen være en Leverandør, som tillater lat evaluering av det.

La oss begynne å se på påstandene som er tilgjengelige også i JUnit 4.

4.1. assertArrayEquals

De assertArrayEquals påstand bekrefter at den forventede og den faktiske matriser er lik:

@Test offentlig ugyldig nårAssertingArraysEquality_thenEqual () {char [] expected = {'J', 'u', 'p', 'i', 't', 'e', ​​'r'}; char [] actual = "Jupiter" .toCharArray (); assertArrayEquals (forventet, faktisk, "Arrays skal være like"); }

Hvis matriser ikke er like, vises meldingen “Arrangementer skal være like”Vises som utdata.

4.2. hevderEquals

I tilfelle vi vil hevde de to flyter er like, kan vi bruke det enkle hevderEquals påstand:

@Test offentlig ugyldig nårAssertingEquality_thenEqual () {float square = 2 * 2; flyterektangel = 2 * 2; assertEquals (kvadrat, rektangel); }

Men hvis vi vil hevde at den faktiske verdien avviker med en forhåndsdefinert delta fra den forventede verdien, kan vi fortsatt bruke hevderEquals men vi må passere deltaverdien som den tredje parameteren:

@Test offentlig ugyldig nårAssertingEqualityWithDelta_thenEqual () {float square = 2 * 2; flyterektangel = 3 * 2; flyte delta = 2; assertEquals (kvadrat, rektangel, delta); }

4.3. hevder sant og hevder falske

Med hevder sant påstand, er det mulig å bekrefte at de leverte forholdene er ekte:

@Test offentlig ugyldig nårAssertingConditions_thenVerified () {assertTrue (5> 4, "5 er større enn 4"); assertTrue (null == null, "null er lik null"); }

Takket være støtten til lambdauttrykket er det mulig å levere en Boolsk leverandør til påstanden i stedet for en boolsk tilstand.

La oss se hvordan vi kan hevde riktigheten av en Boolsk leverandør bruker hevder falske påstand:

@Test offentlig ugyldig givenBooleanSupplier_whenAssertingCondition_thenVerified () {BooleanSupplier condition = () -> 5> 6; assertFalse (tilstand, "5 er ikke større enn 6"); }

4.4. hevder Null og hevderNotNull

Når vi vil hevde at et objekt ikke er det null vi kan bruke hevderNotNull påstand:

@Test offentlig ugyldig nårAssertingNotNull_thenTrue () {Object dog = new Object (); assertNotNull (hund, () -> "Hunden skal ikke være null"); }

På motsatt måte kan vi bruke hevder Null påstand for å sjekke om den faktiske er null:

@Test offentlig ugyldig nårAssertingNull_thenTrue () {Object cat = null; assertNull (cat, () -> "Katten skal være null"); }

I begge tilfeller vil feilmeldingen bli hentet på en lat måte siden den er en Leverandør.

4.5. hevderSamme og assertNotSame

Når vi vil hevde at det forventede og det faktiske refererer til det samme Gjenstand, må vi bruke hevderSamme påstand:

@Test offentlig ugyldig nårAssertingSameObject_thenSuccessfull () {String språk = "Java"; Valgfritt valgfritt = Valgfritt. Av (språk); assertSame (språk, valgfritt. get ()); }

På motsatt måte kan vi bruke assertNotSame en.

4.6. mislykkes

De mislykkes påstand mislykkes en test med den medfølgende feilmeldingen, samt den underliggende årsaken. Dette kan være nyttig for å markere en test når utviklingen ikke er fullført:

@Test offentlig ugyldig nårFailingATest_thenFailed () {// Testen ikke fullført mislyktes ("FAIL - test not complete"); }

4.7. hevderAlle

En av de nye påstandene som ble introdusert i JUnit 5 er hevderAlle.

Denne påstanden gjør det mulig å lage grupperte påstander, der alle påstandene blir utført og deres feil rapporteres sammen. I detalj godtar denne påstanden en overskrift som vil bli inkludert i meldingsstrengen for MultipleFailureError, og en Strøm av Kjørbar.

La oss definere en gruppert påstand:

@Test offentlig ugyldig gittMultipleAssertion_whenAssertingAll_thenOK () {assertAll ("heading", () -> assertEquals (4, 2 * 2, "4 is 2 times 2"), () -> assertEquals ("java", "JAVA" .toLowerCase ()), () -> assertEquals (null, null, "null er lik null")); }

Utførelsen av en gruppert påstand avbrytes bare når en av kjørbarne kaster et svartelistet unntak (OutOfMemoryError for eksempel).

4.8. assertIterableEquals

De assertIterableEquals hevder at forventede og faktiske iterables er dypt like.

For å være lik, må begge iterable returnere like elementer i samme rekkefølge, og det kreves ikke at de to iterables er av samme type for å være like.

La oss se på hvordan vi kan hevde at to lister av forskjellige typer (LinkedList og ArrayList for eksempel) er like:

@Test offentlig ugyldighet gittTwoLists_whenAssertingIterables_thenEquals () {Iterable al = new ArrayList (asList ("Java", "Junit", "Test")); Iterable ll = new LinkedList (asList ("Java", "Junit", "Test")); assertIterableEquals (al, ll); }

På samme måte som assertArrayEquals, hvis begge iterables er null, anses de som like.

4.9. assertLinesMatch

De assertLinesMatch hevder at den forventede listen over String samsvarer med den faktiske listen.

Denne metoden skiller seg fra hevderEquals og assertIterableEquals siden den utfører denne algoritmen for hvert par forventede og faktiske linjer:

  1. sjekk om den forventede linjen er lik den faktiske. Hvis ja, fortsetter det med neste par
  2. behandle forventet linje som et vanlig uttrykk og utfører en sjekk med String.fyrstikker() metode. Hvis ja, fortsetter det med neste par
  3. sjekk om den forventede linjen er en fremover markør. Hvis ja, bruk fremover og gjenta algoritmen fra trinn 1

La oss se hvordan vi kan bruke denne påstanden for å hevde at to lister over String har samsvarende linjer:

@Test offentlig ugyldig nårAssertingEqualityListOfStrings_thenEqual () {List expected = asList ("Java", "\ d +", "JUnit"); List actual = asList ("Java", "11", "JUnit"); assertLinesMatch (forventet, faktisk); }

4.10. assertNotEquals

Utfyllende til hevderEquals, den assertNotEquals påstand hevder at forventede og faktiske verdier ikke er like:

@Test offentlig ugyldig nårAssertingEquality_thenNotEqual () {Integer value = 5; // resultat av en algoritme assertNotEquals (0, verdi, "Resultatet kan ikke være 0"); }

Hvis begge er det null, påstanden mislykkes.

4.11. hevder Kaster

For å øke enkelhet og lesbarhet, den nye hevder Kaster påstand gir oss en klar og enkel måte å hevde om en kjørbar kaster den spesifiserte unntakstypen.

La oss se hvordan vi kan hevde et kastet unntak:

@Test ugyldig nårAssertingException_thenThrown () {Throwable exception = assertThrows (IllegalArgumentException.class, () -> {throw new IllegalArgumentException ("Exception message");}); assertEquals ("Unntaksmelding", exception.getMessage ()); }

Påstanden vil mislykkes hvis det ikke kastes noe unntak, eller hvis det kastes et unntak av en annen type.

4.12. assertTimeout og assertTimeoutForebyggende

I tilfelle vi ønsker å hevde at utførelsen av en levert Kjørbar slutter før en gitt Pause, kan vi bruke assertTimeout påstand:

@Test offentlig ugyldig nårAssertingTimeout_thenNotExceeded () {assertTimeout (ofSeconds (2), () -> {// kode som krever mindre enn 2 minutter å utføre Thread.sleep (1000);}); }

Imidlertid med assertTimeout påstand, vil den medfølgende kjørbare filen bli kjørt i samme tråd som ringekoden. Følgelig vil utførelse av leverandøren ikke avbrytes preemptively hvis tidsavbruddet overskrides.

Hvis vi vil være sikre på at kjøringen av den kjørbare filen blir avbrutt når den overstiger tidsavbruddet, kan vi bruke assertTimeoutForebyggende påstand.

Begge påstandene kan akseptere, i stedet for en Kjørbar, en ThrowingSupplier, som representerer en generell kodeblokk som returnerer et objekt og som potensielt kan kaste a Kastbar.

5. Konklusjon

I denne opplæringen dekket vi alle påstandene som er tilgjengelige i både JUnit 4 og JUnit 5.

Vi fremhevet kort forbedringene som ble gjort i JUnit 5, med introduksjonene av nye påstander og støtten fra lambdas.

Som alltid er den fullstendige kildekoden for denne artikkelen tilgjengelig på GitHub.