Java >> Java tutorial >  >> Tag >> assert

Påstande i JUnit 4 og JUnit 5

assert

1. Introduktion

I denne artikel vil vi i detaljer undersøge de påstande, der er tilgængelige i JUnit.

Efter migreringen fra JUnit 4 til JUnit 5 og A Guide to JUnit 5-artikler, går vi nu ind på detaljer om de forskellige påstande, der er tilgængelige i JUnit 4 og JUnit 5.

Vi vil også fremhæve de forbedringer, der er lavet på påstandene med JUnit 5.

2. Påstande

Påstande er hjælpemetoder til at understøtte at hævde betingelser i test; disse metoder er tilgængelige via Bekræftelse klasse, i JUnit 4, og påstandene en, i JUnit 5.

For at øge læsbarheden af ​​testen og selve påstandene, anbefales det altid at importere statisk den respektive klasse. På denne måde kan vi referere direkte til selve påstandsmetoden uden den repræsenterende klasse som et præfiks.

Lad os begynde at udforske de påstande, der er tilgængelige med JUnit 4.

3. Påstande i JUnit 4

I denne version af biblioteket er påstande tilgængelige for alle primitive typer, Objekter, og arrays (enten af ​​primitiver eller objekter).

Parameterrækkefølgen i påstanden er den forventede værdi efterfulgt af den faktiske værdi; den første parameter kan eventuelt være en streng meddelelse, der repræsenterer meddelelsesoutput af den evaluerede tilstand.

Der er kun én lidt anderledes i, hvordan assertThat defineres påstande, men vi vil dække det senere.

Lad os starte med assertEquals en.

3.1. assertEquals

assertEquals påstand verificerer, at de forventede og de faktiske værdier er ens:

@Test
public void whenAssertingEquality_thenEqual() {
    String expected = "Baeldung";
    String actual = "Baeldung";

    assertEquals(expected, actual);
}

Det er også muligt at angive en meddelelse, der skal vises, når påstanden mislykkes:

assertEquals("failure - strings are not equal", expected, actual);

3.2. assertArrayEquals

Hvis vi vil hævde, at to arrays er ens, kan vi bruge assertArrayEquals: 

@Test
public void whenAssertingArraysEquality_thenEqual() {
    char[] expected = {'J','u','n','i','t'};
    char[] actual = "Junit".toCharArray();
    
    assertArrayEquals(expected, actual);
}

Hvis begge arrays er null , vil påstanden betragte dem som ligeværdige:

@Test
public void givenNullArrays_whenAssertingArraysEquality_thenEqual() {
    int[] expected = null;
    int[] actual = null;

    assertArrayEquals(expected, actual);
}

3.3. assertNotNull og assertNull

Når vi vil teste om et objekt er nul vi kan bruge assertNull påstand:

@Test
public void whenAssertingNull_thenTrue() {
    Object car = null;
    
    assertNull("The car should be null", car);
}

På den modsatte måde, hvis vi vil hævde, at et objekt ikke skal være nul, kan vi bruge assertNotNull-påstanden.

3.4. assertNotSame og assertSame

Med assertNotSame , er det muligt at verificere, om to variabler ikke refererer til det samme objekt:

@Test
public void whenAssertingNotSameObject_thenDifferent() {
    Object cat = new Object();
    Object dog = new Object();

    assertNotSame(cat, dog);
}

Ellers, når vi vil verificere, at to variable refererer til det samme objekt, kan vi bruge assertSame påstand.

3.5. assertTrue og assertFalse

I tilfælde af at vi ønsker at bekræfte, at en bestemt betingelse er sand eller falsk , kan vi henholdsvis bruge assertTrue påstand eller assertFalse en:

@Test
public void whenAssertingConditions_thenVerified() {
    assertTrue("5 is greater then 4", 5 > 4);
    assertFalse("5 is not greater then 6", 5 > 6);
}

3.6. mislykkedes

mislykket assertion mislykkes i en test, der kaster en AssertionFailedError . Det kan bruges til at verificere, at en faktisk undtagelse er smidt, eller når vi ønsker at få en test til at mislykkes under udviklingen.

Lad os se, hvordan vi kan bruge det i det første scenarie:

@Test
public void whenCheckingExceptionMessage_thenEqual() {
    try {
        methodThatShouldThrowException();
        fail("Exception not thrown");
    } catch (UnsupportedOperationException e) {
        assertEquals("Operation Not Supported", e.getMessage());
    }
}

3.7. assertThat

assertThat assertion er den eneste i JUnit 4, der har en omvendt rækkefølge af parametrene sammenlignet med de andre påstande.

I dette tilfælde har påstanden en valgfri fejlmeddelelse, den faktiske værdi og en Matcher objekt.

Lad os se, hvordan vi kan bruge denne påstand til at kontrollere, om et array indeholder bestemte værdier:

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

Yderligere oplysninger om den effektive brug af assertThat påstand med Matcher objekt, er tilgængelig på Test med Hamcrest.

4. JUnit 5-påstande

JUnit 5 beholdt mange af påstandsmetoderne i JUnit 4, mens de tilføjede få nye, der drager fordel af Java 8-understøttelsen.

Også i denne version af biblioteket er påstande tilgængelige for alle primitive typer, Objekter, og arrays (enten af ​​primitiver eller objekter).

Rækkefølgen af ​​parametrene for påstandene ændrede sig og flyttede outputmeddelelsesparameteren som den sidste parameter. Takket være understøttelsen af ​​Java 8 kan outputmeddelelsen være en leverandør , hvilket tillader doven evaluering af det.

Lad os begynde at gennemgå de påstande, der allerede havde en JUnit 4-ækvivalent.

4.1. assertArrayEquals

assertArrayEquals påstand verificerer, at de forventede og de faktiske arrays er ens:

@Test
public void whenAssertingArraysEquality_thenEqual() {
    char[] expected = { 'J', 'u', 'p', 'i', 't', 'e', 'r' };
    char[] actual = "Jupiter".toCharArray();

    assertArrayEquals(expected, actual, "Arrays should be equal");
}

Hvis arrays ikke er ens, meddelelsen "Arrays should be equal ” vil blive vist som output.

4.2. assertEquals

I tilfælde af at vi vil hævde, at to flydere er lig, kan vi bruge de simple assertEquals påstand:

@Test
void whenAssertingEquality_thenEqual() {
    float square = 2 * 2;
    float rectangle = 2 * 2;

    assertEquals(square, rectangle);
}

Men hvis vi ønsker at hævde, at den faktiske værdi afviger med et foruddefineret delta fra den forventede værdi, kan vi stadig bruge assertEquals men vi skal sende deltaværdien som den tredje parameter:

@Test
void whenAssertingEqualityWithDelta_thenEqual() {
    float square = 2 * 2;
    float rectangle = 3 * 2;
    float delta = 2;

    assertEquals(square, rectangle, delta);
}

4.3. assertTrue og assertFalse

Med assertTrue påstand, er det muligt at bekræfte, at de leverede betingelser er sande :

@Test
void whenAssertingConditions_thenVerified() {
    assertTrue(5 > 4, "5 is greater the 4");
    assertTrue(null == null, "null is equal to null");
}

Takket være støtten fra lambda-udtrykket er det muligt at levere en BooleanSupplier til påstanden i stedet for en boolsk tilstand.

Lad os se, hvordan vi kan hævde rigtigheden af ​​en BooleanSupplier ved at bruge assertFalse påstand:

@Test
public void givenBooleanSupplier_whenAssertingCondition_thenVerified() {
    BooleanSupplier condition = () -> 5 > 6;

    assertFalse(condition, "5 is not greater then 6");
}

4.4. assertNull og assertNotNull

Når vi vil hævde, at et objekt ikke er null vi kan bruge assertNotNull påstand:

@Test
void whenAssertingNotNull_thenTrue() {
    Object dog = new Object();

    assertNotNull(dog, () -> "The dog should not be null");
}

På den modsatte måde kan vi bruge assertNull påstand for at kontrollere, om den faktiske er nul :

@Test
public void whenAssertingNull_thenTrue() {
    Object cat = null;

    assertNull(cat, () -> "The cat should be null");
}

I begge tilfælde vil fejlmeddelelsen blive hentet på en doven måde, da det er en leverandør .

4.5. assertSame og assertNotSame

Når vi vil hævde, at det forventede og det faktiske refererer til det samme Objekt , skal vi bruge assertSame påstand:

@Test
void whenAssertingSameObject_thenSuccessfull() {
    String language = "Java";
    Optional<String> optional = Optional.of(language);

    assertSame(language, optional.get());
}

På den modsatte måde kan vi bruge assertNotSame en.

4.6. mislykket

mislykket påstand mislykkes en test med den medfølgende fejlmeddelelse samt den underliggende årsag. Dette kan være nyttigt for at markere en test, når dens udvikling ikke er fuldført:

@Test
public void whenFailingATest_thenFailed() {
    // Test not completed
    fail("FAIL - test not completed");
}

4.7. assertAll

En af de nye påstande introduceret i JUnit 5 er assertAll .

Denne påstand tillader oprettelsen af ​​grupperede påstande, hvor alle påstande udføres, og deres fejl rapporteres samlet. I detaljer accepterer denne påstand en overskrift, der vil blive inkluderet i meddelelsesstrengen for MultipleFailureError og en Strøm af Eksekverbar.

Lad os definere en grupperet påstand:

@Test
void givenMultipleAssertion_whenAssertingAll_thenOK() {
    Object obj = null;
    assertAll(
      "heading",
      () -> assertEquals(4, 2 * 2, "4 is 2 times 2"),
      () -> assertEquals("java", "JAVA".toLowerCase()),
      () -> assertNull(obj, "obj is null")
    );
}

Udførelsen af ​​en grupperet påstand afbrydes kun, når en af ​​de eksekverbare filer kaster en sortlistet undtagelse (OutOfMemoryError for eksempel).

4.8. assertIterableEquals

assertIterableEquals hævder, at de forventede og de faktiske iterables er dybt lige store.

For at være ens skal begge iterable returnere lige store elementer i samme rækkefølge, og det er ikke påkrævet, at de to iterables er af samme type for at være ens.

Med denne betragtning, lad os se, hvordan vi kan hævde, at to lister af forskellige typer (LinkedList og ArrayList for eksempel) er ens:

@Test
void givenTwoLists_whenAssertingIterables_thenEquals() {
    Iterable<String> al = new ArrayList<>(asList("Java", "Junit", "Test"));
    Iterable<String> ll = new LinkedList<>(asList("Java", "Junit", "Test"));

    assertIterableEquals(al, ll);
}

På samme måde som assertArrayEquals , hvis begge iterables er nul, anses de for at være lige store.

4.9. assertLinesMatch

assertLinesMatch hævder, at den forventede liste over String matcher den faktiske liste.

Denne metode adskiller sig fra assertEquals og assertIterableEquals da den for hvert par forventede og faktiske linjer udfører denne algoritme:

  1. kontroller, om den forventede linje er lig med den faktiske. Hvis ja, fortsætter det med det næste par
  2. behandle den forventede linje som et regulært udtryk og udføre en kontrol med strengen .matches() metode. Hvis ja, fortsætter det med det næste par
  3. kontroller, om den forventede linje er en fremspolingsmarkør. Hvis ja, spol frem og gentag algoritmen fra trin 1

Lad os se, hvordan vi kan bruge denne påstand til at hævde, at to lister med streng har matchende linjer:

@Test
void whenAssertingEqualityListOfStrings_thenEqual() {
    List<String> expected = asList("Java", "\\d+", "JUnit");
    List<String> actual = asList("Java", "11", "JUnit");

    assertLinesMatch(expected, actual);
}

4.10. assertNotEquals

Supplerende til assertEquals , assertNotEquals påstand hævder, at de forventede og de faktiske værdier ikke er ens:

@Test
void whenAssertingEquality_thenNotEqual() {
    Integer value = 5; // result of an algorithm
    
    assertNotEquals(0, value, "The result cannot be 0");
}

Hvis begge er null , påstanden mislykkes.

4.11. assertThrows

For at øge enkelheden og læsbarheden er de nye assertThrows assertion giver os en klar og enkel måde at hævde, hvis en eksekverbar afgiver den angivne undtagelsestype.

Lad os se, hvordan vi kan hævde en smidt undtagelse:

@Test
void whenAssertingException_thenThrown() {
    Throwable exception = assertThrows(
      IllegalArgumentException.class, 
      () -> {
          throw new IllegalArgumentException("Exception message");
      }
    );
    assertEquals("Exception message", exception.getMessage());
}

Påstanden vil mislykkes, hvis der ikke kastes nogen undtagelse, eller hvis en undtagelse af en anden type er kastet.

4.12. assertTimeout og assertTimeoutPreemptively

I tilfælde af at vi ønsker at hævde, at udførelsen af ​​en leveret eksekverbar slutter før en given Timeout , kan vi bruge assertTimeout påstand:

@Test
void whenAssertingTimeout_thenNotExceeded() {
    assertTimeout(
      ofSeconds(2), 
      () -> {
        // code that requires less than 2 minutes to execute
        Thread.sleep(1000);
      }
    );
}

Men med assertTimeout påstand, vil den leverede eksekverbare blive eksekveret i den samme tråd i den kaldende kode. Følgelig vil eksekveringen af ​​leverandøren ikke blive afbrudt forebyggende, hvis timeout overskrides.

Hvis vi vil være sikre på, at eksekveringen afbrydes, når den overskrider timeout, kan vi bruge assertTimeoutPreemptively påstand.

Begge påstande kan acceptere, i stedet for en Eksekverbar, en ThrowingSupplier , der repræsenterer enhver generisk kodeblok, der returnerer et objekt, og som potentielt kan kaste en Throwable.

5. Konklusion

I denne tutorial dækkede vi alle de påstande, der er tilgængelige i både JUnit 4 og JUnit 5.

Vi fremhævede kort de forbedringer, der er foretaget i JUnit 5, med introduktioner af nye påstande og støtte fra lambdaer.

Som altid er den komplette kildekode til denne artikel tilgængelig på GitHub.


Java tag