JUnit-påstander

6.1 hevder

Påstander er spesielle sjekker som kan settes inn på forskjellige steder i koden. Deres oppgave er å fastslå at noe gikk galt. Eller rettere sagt, for å sjekke at alt går som det skal. Dette er "etter behov", og de lar deg stille det på forskjellige måter.

Du har allerede møtt noen påstander i koden ovenfor. Den første er å sjekke objekter for likhet. Hvis objektene ikke er like, vil et unntak bli kastet og testen vil mislykkes.

Sammenligningsrekkefølgen er viktig her , fordi JUnit i sluttrapporten vil skrive noe sånt som "verdi 1 mottatt, men 3 var forventet". Det generelle formatet for en slik sjekk er:

assertEquals(standard , meaning)

Eksempel:

@Test
public void whenAssertingEquality () {
    String expected = "3.1415";
    String actual = "3";

    assertEquals(expected, actual);
}

6.2 Metoder assertEquals, assertTrue, assertFalse

Nedenfor vil jeg liste opp de mest populære metodene - påstander. Ved navnene deres er det fullt mulig å gjette hvordan de fungerer. Men jeg skal likevel skrive en kort forklaring:

Noen av disse metodene virker overflødige. Hvorfor bruke assertSame(a, b) når du bare kan skrive assertTrue(a == b) ?

Poenget er at assert er en veldig smart metode. Den gjør mange nyttige ting, inkludert å skrive feilinformasjon til loggen . I det første tilfellet vil den skrive at objekt A var forventet, men objekt B ble mottatt. I det andre tilfellet vil den ganske enkelt skrive at sant var forventet .

Når du har hundrevis av tester, spesielt de som kjører på en dedikert testserver, kan det være veldig nyttig å ha detaljerte logger. Jeg tror du forstår hva jeg mener.

Eksempel på sammenligning av matriser:

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

    assertArrayEquals(expected, actual);
}

6.3 assertAll-metoden

Som nevnt ovenfor utfører assertmetoden ikke bare en sjekk, men skriver også mye informasjon om sammenlignbare objekter til loggen.

La oss gjøre en sammenligning:

Address address = unitUnderTest.methodUnderTest();
assertEquals("Washington", address.getCity());
assertEquals("Oracle Parkway", address.getStreet());
assertEquals("500", address.getNumber());

Men hvis en av parameterne ikke stemmer overens, vil ikke resten bli sjekket. Men jeg vil at de fortsatt skal forekomme og resultatene deres blir registrert i loggen. Men på samme tid, hvis minst en sjekk mislyktes, så mislyktes testen fortsatt.

Det er en spesiell metode for dette - assertAll() . Som det første argumentet kreves det en kommentar for å bli skrevet til loggen, og deretter et hvilket som helst antall påstandsfunksjoner.

Her er hvordan vårt eksempel vil bli skrevet om med det:

Address address = unitUnderTest.methodUnderTest();
assertAll("Complex address comparison script",
    () -> assertEquals("Washington", address.getCity()),
    () -> assertEquals("Oracle Parkway", address.getStreet()),
    () -> assertEquals("500", address.getNumber())
);

Så hvis adressen er feil, vil noe sånt som dette bli skrevet til loggen:

	Complex scenario comparison address (3 failures)
	expected: <Washington> but was: <Seattle>
    expected: <Oracle Parkway> but was: <Main Street>
    expected: <500> but was: <5772>

6.4 assertTimeout-metoden

Husker du @Timeout -kommentaren ? Det tillot å kontrollere utførelsestiden for hele metoden. Men noen ganger er det nyttig å sette begrensninger på utførelse av en del av koden inne i metoden. Du kan bruke assertTimeout() for dette .

Tiden passeres som den første parameteren, og koden (funksjonen) som må utføres innen den angitte tiden, sendes som den andre. Eksempel:

@Test
public void whenAssertingTimeout() {
    assertTimeout(
  	ofSeconds(2),
  	() -> {
    	// pause for one second
    	Thread.sleep(1000);
  	}
	);
}

Assert- klassen har 12 varianter av assertTimeout() -metoden . Hvis du vil lære mer om dem, velkommen til den offisielle dokumentasjonen .

6.5 assertThrows-metoden

Svært ofte er det situasjoner når du må sørge for at koden i en bestemt situasjon kaster det riktige unntaket: den oppdager en feil og kaster det riktige unntaket. Dette er en veldig vanlig situasjon.

I dette tilfellet er det en annen nyttig assertmetode - dette er assertThrows() . Det generelle formatet for samtalen er:

assertThrows(exception , code)

I utgangspunktet er den veldig lik assertTimeout()- metoden , bare den sjekker at den angitte koden kaster det riktige unntaket. Eksempel:

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