JUnit Verwachte uitzonderingstest: @Test(verwacht)

JUnit biedt de mogelijkheid om trace de uitzondering en ook om te controleren of de code de verwachte uitzondering genereert of niet.

JUnit 4 biedt een eenvoudige en leesbare manier voor het testen op uitzonderingen. Je kunt het volgende gebruiken:

• De optionele parameter (verwacht) van de @Test-annotatieen
• Naar trace de informatie, “fail()” kan worden gebruikt.

Terwijl het testen van Bij een uitzondering moet u ervoor zorgen dat de uitzonderingsklasse die u in die optionele parameter van de opgeeft, correct is. @Test-annotatie is dezelfde uitzondering die de methode daadwerkelijk genereert. Dit komt omdat je een uitzondering verwacht van de methode die je aanroept. testen van een eenheidanders onze JUnit proef zou mislukken.

Voorbeeld: @Test(expected = IllegalArgumentException.class)

Met de parameter "expected" kunt u de naam van de uitzondering specificeren die onze test mogelijk zal genereren. In het bovenstaande voorbeeld gebruikt u "IllegalArgumentException", die door de test wordt gegenereerd als een ontwikkelaar een argument gebruikt dat niet is toegestaan.

Voorbeeld met @Test(expected)

Laten we het testen van uitzonderingen begrijpen door een voorbeeld te maken. Java klasse met een methode die een uitzondering genereert uitzonderingJe zult het afhandelen en testen in een testklasse. Overweeg dit eens. JUnitHet bestand Message.java bevat een methode die een wiskundige bewerking uitvoert. De deling op regel 14 deelt door nul, waardoor de methode altijd een "ArithmeticException" genereert. Zie hieronder:

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 Uitleg:

• Code Regel 7: Een geparametriseerde constructor maken met veldinitialisatie.
• Code Lijn 11-14: Een methode ontwikkelen voor de wiskundige bewerking.
• Code Regel 18: Een andere methode creëren om een ​​bericht af te drukken.
• Code Regel 20: Een nieuwe string maken om een ​​bericht af te drukken.
• Code Regel 22: Het nieuwe bericht dat in regel 20 is aangemaakt, wordt afgedrukt.

Laten we een testklasse maken voor het bovenstaande. Java klasse om de uitzondering te verifiëren.

Hieronder ziet u de testklasse die de uitzondering (hier ArithmeticException) test die hierboven wordt gegenereerd. Java klasse:

AirthematicTest.java

De onderstaande schermafbeelding toont dezelfde test in de editor, waar het bestand is opgeslagen als AirthematicTest1, met de verwachte parameter gemarkeerd op regel 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 Uitleg:

• Code Regel 13: We gebruiken de `@Test`-annotatie om onze test te maken. Wanneer je de methode van de bovenstaande klasse uitvoert, wordt er een wiskundige bewerking uitgevoerd. Hier wordt een `ArithmeticException` verwacht, dus die geef je op als parameter in `@Test`.
• Code Regel 17: printMessage() aanroepen vanuit JUnitBericht.java.
• Code Lijn 21-22: Een nieuwe testmethode maken om het bericht "Hi" te controleren, dit keer zonder de verwachte parameter.

De klasse bevat twee testmethoden, waardoor beide methoden bij één uitvoering worden uitgevoerd: de methode die een ArithmeticException verwacht en de methode die een controle uitvoert op de geretourneerde tekenreeks.

Let op: Dit voorbeeld wordt in het originele materiaal onder drie namen genoemd: in de code wordt de klasse AirthematicTest genoemd, in de schermafbeelding van de editor staat AirthematicTest1 en in de resultaatweergave wordt JunitTestExample weergegeven. De code is in alle gevallen identiek; alleen de bestandsnaam verschilt.

Laten we het uitvoeren en het resultaat controleren. JUnit Onderstaande weergave laat de uitvoering zien JunitTestExample.java.

Output:

Hier is de uitvoer, die een succesvolle test zonder fouten laat zien. trace zoals hieronder weergegeven:

Beide methoden zijn groen. De eerste slaagt omdat de gedeclareerde ArithmeticException daadwerkelijk is opgetreden, en de tweede slaagt omdat de geretourneerde tekenreeks overeenkomt. Als de deling nooit een uitzondering had gegenereerd, JUnit De eerste methode zou zijn mislukt met de melding "Verwachte uitzondering: java.lang.ArithmeticException".

Drie manieren om een ​​uitzondering te testen in JUnit 4

De verwachte parameter is de kortste van de drie. JUnit Vier uitdrukkingen, maar het is niet altijd de juiste. De tabel vergelijkt ze aan de hand van twee vragen die de keuze bepalen: kun je iets zeggen over de boodschap, en weet je welke lijn je hebt getrokken?

Het fail()-idioom dat in de inleiding wordt genoemd, ziet er als volgt uit. Als de aanroep geen uitzondering genereert, wordt fail() uitgevoerd en rapporteert de test het bericht dat je hebt geschreven:

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

De ExpectedException-regel bevindt zich tussen de twee in. Deze is afgekeurd in JUnit 4.13 ten gunste van de hierna beschreven assertThrows-methode, dus nieuw JUnit 4 tests zouden dit niet moeten overnemen.

Hoe test je uitzonderingen in JUnit 5 met assertThrows()

JUnit 5 verwijdert de verwachte parameter volledig uit @Test. Jupiter levert assertThrows()Deze functie neemt de uitzonderingsklasse en een lambda-uitdrukking met de te testen code als argumenten. De functie retourneert de opgevangen uitzondering, zodat het bericht, de oorzaak en eventuele aangepaste velden daarna gecontroleerd kunnen worden.

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());
    }
}

Drie gerelateerde beweringen Maak het gezin compleet:

• assertThrows accepteert het uitzonderingstype of een subklasse daarvan.
• assertThrowsExactly Een subklasse wordt afgewezen, dus alleen het benoemde type wordt geaccepteerd.
• assertDoesNotThrow Het stelt de tegenovergestelde verwachting vast, namelijk dat het blok netjes wordt voltooid.

De JUnit 4 code op deze pagina werkt nog steeds op de JUnit Het platform draait op de oude engine, dus er hoeft niets van het bovenstaande te worden herschreven om te blijven werken tijdens een projectmigratie.

Veelgemaakte fouten bij het testen van uitzonderingen in JUnit

Uitzonderingstests falen op een klein aantal herkenbare manieren. Elke regel vermeldt het symptoom, de oorzaak en de oplossing.

De laatste regel is degene waar de meeste mensen tijdens de migratie tegenaan lopen, omdat beide annotaties @Test heten en alleen de import ze van elkaar onderscheidt. Keeping een JUnit versie per testcase De les vermijdt het hele probleem.

Veelgestelde vragen