JUnit Test Cases @Before @BeforeClass Annotation

โšก Smart opsummering

JUnit er det mest anvendte enhedstestframework til Java, og dens testfixture-annotationer styrer prรฆcis, hvad der sker fรธr og efter hver testmetode kรธrer i en testklasse.

  • ๐Ÿ”˜ Fixture: En testfixture er den faste kontekst af objekter og ressourcer, som en testcase kรธrer i.
  • โ˜‘๏ธ Opsรฆtning: @Before kรธres fรธr hver testmetode, mens @BeforeClass kรธres รฉn gang fรธr hele klassen.
  • โœ… Rive ned: @After kรธrer efter hver test, selv nรฅr testen udlรธser et problem, eller en assertion fejler.
  • ๐Ÿงช Order: Superklassen @Before kรธrer fรธrst, derefter underklassen @Before, @Test, og derefter hver @Efter.
  • ๐Ÿ› ๏ธ Lรธber: JUnitCore.runClasses() udfรธrer testklasser og returnerer et Result-objekt, der indeholder alle fejl.
  • ๐Ÿ“Š JUnit 5: @Fรธr, @Efter, @FรธrKlasse og @EfterKlasse bliver til @FรธrHver, @EfterHver, @FรธrAlle og @EfterAlle.

JUnit testfixture med @Before- og @BeforeClass-annotationer

JUnit er den mest populรฆre enhed Test rammer i Java. Det anbefales udtrykkeligt til Enhedstest. JUnit krรฆver ikke en server for at teste en webapplikation, hvilket gรธr testprocessen hurtig.

JUnit framework tillader ogsรฅ hurtig og nem generering af testcases og testdata. Det org.junit Pakken bestรฅr af mange grรฆnseflader og klasser til JUnit testning, sรฅsom Test, Assert, Efter og Fรธr. Den bredere JUnit Familien bygger pรฅ de samme byggesten.

Hvad er en testfixtur?

Fรธr vi forstรฅr, hvad en testfixture er, lad os studere koden nedenfor.

Denne kode er designet til at udfรธre to testcases pรฅ en simpel fil.

public class OutputFileTest {
    private File output; 
    output = new File(...);
    output.delete(); 
public void testFile1(){
        //Code to verify Test Case 1
}
    output.delete();
    output = new File(...);
public void testFile2(){
        //Code to verify Test Case 2
}
 output.delete(); 
}

Lidt problemer her

  • Koden er ikke lรฆsbar.
  • Koden er ikke nem at vedligeholde.
  • Nรฅr testpakken er kompleks, kan koden indeholde logiske problemer.

Sammenlign den samme kode vha JUnit.

public class OutputFileTest		
{
    private File output; 
    @Before public void createOutputFile() 
    { 
       output = new File(...);
    }
  
	@After public void deleteOutputFile() 
    {
        output.delete(); 
    } 
     
    @Test public void testFile1() 
    {
       // code for test case objective
    } 
	@Test public void testFile2() 
    {
       // code for test case objective
    }
}

Koden er langt mere lรฆsbar og vedligeholdelsesvenlig. Ovenstรฅende kodestruktur er en testarmatur.

Et testarmatur er en kontekst, hvor en JUnit Test sag lรธber. Typisk inkluderer testarmaturer:

  • Objekter eller ressourcer, der er tilgรฆngelige for enhver testcase.
  • Aktiviteter, der krรฆves for at gรธre disse objekter og ressourcer tilgรฆngelige.
  • Disse aktiviteter er
    1. tildeling (setup)
    2. de-allokering (rive ned).

Opsรฆtning og nedtagning

Inventar er vigtige fordi JUnit kรธrer disse hooks rundt om hver test.

  • Normalt er der nogle gentagne opgaver, der skal udfรธres forud for hver testcase. Eksempel: oprette en databaseforbindelse.
  • Ligeledes kan der i slutningen af โ€‹โ€‹hver testcase vรฆre nogle gentagne opgaver. Eksempel: at rydde op, nรฅr testudfรธrelsen er overstรฅet.
  • JUnit indeholder annotationer, der hjรฆlper med opsรฆtning og nedtagning. Det sikrer, at ressourcer frigives, og at testsystemet er klar til den nรฆste testcase.

Disse JUnit Annotationer diskuteres nedenfor.

Opsรฆtning

@Fรธr anmรฆrkning i JUnit bruges pรฅ en metode, der indeholder Java kode, der skal kรธres fรธr hver testcase, det vil sige, den kรธres fรธr hver testudfรธrelse.

Nedbrydning (uanset dommen)

@Efter annotering bruges pรฅ en metode, der indeholder Java kode, der skal kรธres efter hver testcase. Disse metoder kรธrer, selvom der udlรธses undtagelser i testcasen eller i tilfรฆlde af pรฅstandsfejl.

Bemรฆrk:

  • Det er tilladt at have et hvilket som helst antal annoteringer, der er angivet ovenfor.
  • Alle de metoder, der er kommenteret med @Fรธr in JUnit vil kรธre fรธr hver testcase, men de kan kรธre i vilkรฅrlig rรฆkkefรธlge.
  • Du kan arve @Before- og @After-metoder fra en superklasse. Udfรธrelsen er som fรธlger, og det er en standardudfรธrelsesproces i JUnit.
  1. Udfรธr JUnit @Fรธr metoder i superklassen
  2. Udfรธr @Before-metoderne i denne klasse
  3. Udfรธr en @Test-metode i denne klasse
  4. Udfรธr @After-metoderne i denne klasse
  5. Udfรธr @After metoderne i superklassen

JUnit 5-note: disse annotationer er JUnit 4 (org.junit). JUnit 5 omdรธbte dem i org.junit.jupiter.api, og JUnit 4-koden nedenfor kรธrer stadig under den gamle motor.

JUnit 4 annotering JUnit 5 (Jupiter) tilsvarende Kรธrer
@Fรธr @FรธrHver Fรธr hver testmetode
@Efter @EfterHver Efter hver testmetode
@BeforeClass @FรธrAlle ร‰n gang foran hele klassen
@Efter skole @EfterAlle En gang efter hele klassen
@Ignorere @Handicappet Springer den kommenterede test over

Eksempel: Oprettelse af en klasse med fil som testfixture

public class OutputFileTest		
{
    private File output; 
    @Before	public void createOutputFile() 
    { 
       output = new File(...);
    }
  
	@After public void deleteOutputFile() 
    {
        output.delete(); 
    } 
     
    @Test public void testFile1() 
    {
       // code for test case objective
    } 
	@Test public void testFile2() 
    {
       // code for test case objective
    }
}

I ovenstรฅende eksempel vil udfรธrelseskรฆden vรฆre som fรธlger. Diagrammet tracer รฉn opret-test-slet-cyklus pr. testmetode.

JUnit @Fรธr og @Efter udfรธrelseskรฆde omkring to testmetoder

  1. createOutputFile()
  2. testFil1()
  3. sletOutputFile()
  4. createOutputFile()
  5. testFil2()
  6. sletOutputFile()

Antagelse:

testFile1() kรธrer fรธr testFile2(), hvilket ikke er garanteret.

Opsรฆtning kun รฉn gang

  • Det er muligt kun at kรธre en metode รฉn gang for hele testklassen, fรธr nogen af โ€‹โ€‹testene udfรธres, og fรธr evt. @Fรธr metoder).
  • "Engangsopsรฆtning" er nyttig til at starte servere, รฅbne kommunikation og lignende arbejde. Det er tidskrรฆvende at lukke og genรฅbne ressourcer for hver test.
  • Dette kan gรธres ved hjรฆlp af anmรฆrkningen @BeforeClass in JUnit.
@BeforeClass public static void Method_Name() {	
    // class setup code here	
 }	

Metoden skal vรฆre offentligt statisk tomrum, Fordi JUnit kalder det, fรธr der findes nogen testinstans.

Rive ned รฉn gang

  • Ligesom engangsopsรฆtning er der ogsรฅ en engangsoprydningsmetode tilgรฆngelig. Den kรธrer efter alle testcase-metoder og @Efter anmรฆrkninger er blevet udfรธrt.
  • Det er nyttigt til at stoppeping servere og lukning af kommunikationsforbindelser.
  • Dette kan gรธres ved hjรฆlp af @Efter skole anmรฆrkning.
 @AfterClass public static void Method_Name()	
 {	
    // class cleanup code here	
 }	

JUnit Test suiter

Nรฅr faste installationer er pรฅ plads, grupperes og lanceres relaterede testklasser normalt sammen.

Hvis vi รธnsker at udfรธre flere tests i en bestemt rรฆkkefรธlge, kan det gรธres ved at kombinere alle testene รฉt sted. Dette sted kaldes en testsuite. Flere detaljer om, hvordan man udfรธrer testsuiter, og hvordan de bruges i JUnit er dรฆkket af dette tutorial.

JUnit Testlรธber

JUnit giver et vรฆrktรธj til udfรธrelse af dine testcases.

  • JUnitCore klasse bruges til at udfรธre disse tests.
  • En metode kaldet kรธre klasser fra org.junit.runner.JUnitCore bruges til at kรธre en eller flere testklasser.
  • Returtype af denne metode er Resultat objekt (org.junit.runner.Result), som bruges til at fรฅ adgang til oplysninger om testene. Se fรธlgende kodeeksempel for mere klarhed.
public class Test {				
			public static void main(String[] args) {									
       		Result result = JUnitCore.runClasses(CreateAndSetName.class);					
			for (Failure failure : result.getFailures()) {							
         		System.out.println(failure.toString());					
      }		
      System.out.println(result.wasSuccessful());					
   }		
}      

I ovenstรฅende kode behandles "result"-objektet for at hente fejl og succesfulde resultater fra de testcases, vi udfรธrer. Hjรฆlpefunktioner som f.eks. assertEquals hรฆve disse fejl, mens @Ignorere springer en test over.

JUnit 5-note: JUnitCore er JUnit 4 lรธber. JUnit 5 erstatter det med JUnit perron Launcher API, normalt startet af IDE'en, Gradle eller Maven Surefire.

Fornavn JUnit Program

Godt kendskab til SDLC, Java programmering og det grundlรฆggende i software test processen hjรฆlper med at forstรฅ en JUnit program, ligesom det at vide hvordan enhedstest adskiller sig fra integrationstests.

Lad os forstรฅ enhedstestning ved hjรฆlp af et live-eksempel. Vi skal oprette en testklasse med en testmetode kommenteret med @Prรธve som angivet nedenfor:

MyFirstClassTest.java

package guru99.JUnit;		

import static org.junit.Assert.*;				

import org.junit.Test;		

public class MyFirstClassTest {				

    @Test		
    public void myFirstMethod(){					
        String str= "JUnit is working fine";					
        assertEquals("JUnit is working fine",str);					
    }
}		

TestRunner.java

For at udfรธre vores testmetode (ovenfor) skal vi oprette en testrunner. I testrunneren skal vi tilfรธje testklassen som en parameter i JUnitCores runClasses()-metode. Den returnerer testresultatet, baseret pรฅ om testen er bestรฅet eller ikke bestรฅet.

For flere detaljer om dette, se koden nedenfor:

package guru99.JUnit;		

import org.junit.runner.JUnitCore;		
import org.junit.runner.Result;		
import org.junit.runner.notification.Failure;		

public class TestRunner {				
			public static void main(String[] args) {									
            Result result = JUnitCore.runClasses(MyFirstClassTest.class);					
			for (Failure failure : result.getFailures()) {							
              System.out.println(failure.toString());					
      }		
      System.out.println("Result=="+result.wasSuccessful());							
   }		
}      	

Produktion

Nรฅr TestRunner.java udfรธrer vores testmetoder, fรฅr vi output som mislykket eller bestรฅet. Se venligst forklaringen pรฅ outputtet nedenfor:

  1. I dette eksempel efter udfรธrelse MyFirstClassTest.java, testen er bestรฅet, og resultatet er grรธnt.
  2. Hvis det var gรฅet galt, ville det have vist resultatet som rรธdt, og fejlen kan observeres i fejlen. trace. Se JUnit GUI nedenfor:

Eclipse JUnit Visning, der viser en grรธn bestรฅelsesbjรฆlke for MyFirstClassTest

Ofte Stillede Spรธrgsmรฅl

JUnit opretter en ny instans af testklassen for hver testmetode, sรฅ der ikke findes nogen instans, hvor klasseniveaukode skal kรธres. Deklarering af metoden static lader JUnit pรฅkalde den direkte.

Nej. Metodens rรฆkkefรธlge er bevidst uspecificeret. JUnit 4 tilbud @FixMethodOrder og JUnit 5 tilbyder @TestMethodOrder, men afhรฆngigt af ordresignaler koblede tests.

Testmetoden kaldes aldrig og rapporteres som en fejl, ikke en fiasko. Enhver @After-metode kรธrer stadig, sรฅ oprydningen skal tolerere en delvist bygget fixture.

Nye projekter bรธr tilfรธje JUnit 5 samlede artefakter org.junit.jupiter:junit-jupiter. Hold med arv JUnit 4 suiter tilfรธjer junit-vintage-engine, sรฅ begge kรธrer pรฅ รฉn platform.

En fixture er hele den forberedte kontekst omkring en test, inklusive rigtige filer eller forbindelser. En mock er en stedfortrรฆdende samarbejdspartner med scriptet adfรฆrd, ofte skabt af fixture'en.

Ja, gennem @BeforeClass i JUnit 4 eller @BeforeAll i JUnit 5. Delte inventar er hurtigere, men har en lรฆkagetilstand, sรฅ reserver dem til dyre skrivebeskyttede ressourcer.

AI-assistenter lรฆser en klasse, udleder de samarbejdspartnere, den har brug for, og udarbejder en @Before-opsรฆtning med matchende @Efter-oprydning. Gennemgรฅ altid selv de genererede assertions.

GitHub Copilot scaffolder en testklasse fra en metodesignatur, inklusive livscyklusannotationer. Standardindstillingen er ofte JUnit 4 importvarer, sรฅ bekrรฆft at pakken passer til din motor.

Opsummer dette indlรฆg med: