JUnit Forventet undtagelsestest: @Test(forventet)

JUnit giver mulighed for at trace undtagelsen og også for at kontrollere, om koden kaster den forventede undtagelse eller ej.

JUnit 4 giver en nem og læsbar metode til undtagelsestestning. Du kan bruge:

• Den valgfrie parameter (forventet) for @Test-annoteringog
• Til tracHvis informationen er korrekt, kan “fail()” bruges.

Mens test en undtagelse, skal du sikre dig, at den undtagelsesklasse, du angiver i den valgfri parameter for @Test-annotering er den samme, som metoden rent faktisk kaster. Dette skyldes, at du forventer en undtagelse fra den metode, du enhedstest; ellers vores JUnit test ville mislykkes.

Eksempel: @Test(forventet = IllegalArgumentException.class)

Ved at bruge parameteren "forventet" kan du angive navnet på den undtagelse, som vores test kan kaste. I eksemplet ovenfor bruger du "Ulovligt argumentundtagelse", som vil blive kastet af testen, hvis en udvikler bruger et argument, der ikke er tilladt.

Eksempel med @Test(forventet)

Lad os forstå undtagelsestestning ved at oprette en Java klasse med en metode, der kaster en undtagelseDu skal håndtere det og teste det i en testklasse. Overvej JUnitMessage.java, som har en metode, der udfører en matematisk operation. Divisionen på linje 14 dividerer med nul, så metoden kaster altid en "ArithmeticException". Se nedenfor:

package guru99.junit;

public class JUnitMessage{

	private String message;

	public JUnitMessage(String message) {
		this.message = message;
	}

public void printMessage(){

	System.out.println(message); 
	int divide=1/0;

}

public String printHiMessage(){ 

	message="Hi!" + message;
	
	System.out.println(message);

	return message;
}

}

Code Forklaring:

• Code Linje 7: Oprettelse af en parameteriseret konstruktør med feltinitialisering.
• Code Linje 11-14: Oprettelse af en metode til den matematiske operation.
• Code Linje 18: Oprettelse af en anden metode til at udskrive en meddelelse.
• Code Linje 20: Oprettelse af en ny streng for at udskrive en besked.
• Code Linje 22: Udskriver den nye besked oprettet i linje 20.

Lad os oprette en testklasse til ovenstående Java klasse for at verificere undtagelsen.

Se nedenfor testklassen, der enhedstester undtagelsen (her ArithmeticException), som udløses ovenfra. Java klasse:

AirthematicTest.java

Skærmbilledet nedenfor viser den samme test i editoren, hvor filen er gemt som AirthematicTest1, med den forventede parameter fremhævet på linje 13:

package guru99.junit;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class AirthematicTest {

	public String message = "Saurabh";
	
	JUnitMessage junitMessage = new JUnitMessage(message);
	
	@Test(expected = ArithmeticException.class)
	public void testJUnitMessage(){

		System.out.println("Junit Message is printing ");
		junitMessage.printMessage();

	}

	@Test
	public void testJUnitHiMessage(){ 
		message="Hi!" + message;
		System.out.println("Junit Message is printing ");
		assertEquals(message, junitMessage.printHiMessage());
	
	}
}

Code Forklaring:

• Code Linje 13: Brug af @Test-annotationen til at oprette vores test. Når du udfører metoden i klassen ovenfor, vil den kalde en matematisk operation. Her forventes ArithmeticException, så du angiver den som en parameter i @Test.
• Code Linje 17: Aktivering af printMessage() fra JUnitMessage.java.
• Code Linje 21-22: Opretter endnu en testmetode til at kontrollere Hi-meddelelsen, denne gang uden en forventet parameter.

Klassen indeholder to testmetoder, så en enkelt kørsel udfører dem begge: den, der forventer ArithmeticException, og den, der assert på den returnerede streng.

Bemærk: Dette eksempel bruges under tre navne i det originale materiale — listen kalder klassen AirthematicTest, skærmbilledet i redigeringsprogrammet viser AirthematicTest1, og resultatvisningen rapporterer JunitTestExample. Koden er identisk i begge; kun filnavnet er forskelligt.

Lad os udføre det og verificere resultatet. JUnit se nedenstående rapporter om forløbet af JunitTestExample.java.

Output:

Her er outputtet, som viser en vellykket test uden fejl trace som angivet nedenfor:

Begge metoder er grønne. Den første bestås, fordi den ArithmeticException, den erklærede, faktisk ankom, og den anden bestås, fordi den returnerede streng matchede. Hvis divisionen aldrig var blevet kastet, JUnit ville have fejlet den første metode med meddelelsen "Forventet undtagelse: java.lang.ArithmeticException".

Tre måder at teste en undtagelse på JUnit 4

Den forventede parameter er den korteste af de tre JUnit 4 idiomer, men det er ikke altid det rigtige. Tabellen sammenligner dem på de to spørgsmål, der afgør valget: kan du hævde budskabet, og ved du hvilken linje der blev kastet?

fail()-idiomet, som introduktionen nævner, ser sådan ud. Hvis kaldet ikke udløser et udfald, køres fail(), og testen rapporterer den besked, du skrev:

@Test
public void testDivideByZero() {
    try {
        junitMessage.printMessage();
        fail("Expected an ArithmeticException");
    } catch (ArithmeticException e) {
        assertEquals("/ by zero", e.getMessage());
    }
}

ExpectedException-reglen ligger mellem de to. Den blev udfaset i JUnit 4.13 til fordel for assertThrows-metoden beskrevet nedenfor, så ny JUnit 4 tests bør ikke anvende det.

Sådan tester du undtagelser i JUnit 5 med assertThrows()

JUnit 5 fjerner den forventede parameter helt fra @Test. Jupiter leverer assertThrows(), som tager exception-klassen og en lambda, der indeholder koden under test. Den returnerer den undtagelse, den fangede, så beskeden, årsagen og ethvert brugerdefineret felt kan hævdes bagefter.

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import org.junit.jupiter.api.Test;

public class AirthematicJupiterTest {

    JUnitMessage junitMessage = new JUnitMessage("Saurabh");

    @Test
    public void testJUnitMessage() {
        ArithmeticException thrown = assertThrows(
                ArithmeticException.class,
                () -> junitMessage.printMessage());
        assertEquals("/ by zero", thrown.getMessage());
    }
}

Tre relaterede påstande rund familien af:

• hævderKast accepterer undtagelsestypen eller enhver underklasse af den.
• hævderKastPræcis afviser en underklasse, så kun den navngivne type består.
• hævderKasterIkke angiver den modsatte forventning, at blokken fuldføres rent.

JUnit 4-koden på denne side kører stadig på JUnit Platform gennem den gamle motor, så intet ovenfor skal omskrives for at fortsætte med at virke, mens et projekt migrerer.

Almindelige fejl ved test af undtagelser i JUnit

Undtagelsestests fejler på et lille antal genkendelige måder. Hver række angiver symptomet, årsagen og løsningen.

Den sidste række er den, der fanger de fleste under migreringen, fordi begge annotationer hedder @Test, og kun importen adskiller dem.ping en JUnit version pr. test sag klasse undgår hele klasseproblemet.

Ofte Stillede Spørgsmål