Formålet med en enhedstest er at identificere fejlene i en applikation så hurtigt som muligt. Selvom flere kanaler kan føre dig til det samme mål, bør du forsøge at bruge den mest effektive rute.
En JUnit-testpakke kan have flere testklasser, der har brug for de samme data, men du kan ikke genbruge testdata. I tidligere versioner af JUnit var en god tilgang at oprette en hjælpemetode og derefter kalde den metode hver gang en testklasse havde brug for sine data.
JUnit 5 giver en mere effektiv tilgang til dette problem: afhængighedsinjektion (DI).
Hvad er afhængighedsinjektion?
DI er et designmønster, hvor et objekt leverer afhængigheder af et andet objekt. Når du bygger et Java-program, har du muligvis en klasse, der afhænger af et objekt, som en anden klasse opretter til at udføre sin funktion.
Før afhængighedsinjektion, for at bruge et objekt fra en anden klasse, skal du oprette en ny forekomst af det objekt inden for klassen, der afhænger af det. Så hvis du havde flere klasser, der er afhængige af det samme objekt, skal du oprette flere forekomster af det inden for de afhængige klasser.
DI giver dig mulighed for at bruge et objekt i en afhængig klasse uden at oprette en ny forekomst af det i den klasse.
Afhængighedsinjektion i JUnit 5
JUnit 5 giver dig mulighed for at injicere afhængigheder i både testmetoder og konstruktører. Dette er væsentligt, da de tidligere versioner af rammeværket ikke tillod testmetoder eller konstruktører at have parametre.
JUnit 5 giver dig mulighed for at injicere så mange parametre, du vil. Den eneste hak er, at ParameterResolver API skal være i stand til at løse hver parameter ved kørsel. JUnit har i øjeblikket tre indbyggede parameteropløsere, som den bruger automatisk. For at bruge enhver anden resolver skal du registrere den eksplicit ved at bruge @ExtendWith-annotationen.
Injicerende afhængigheder i JUnit
Dette eksempelprogram bruger en af JUnits indbyggede parametre (TestInfoParameterResolver) til at demonstrere, hvordan du kan injicere en afhængighed i en JUnit 5 test. TestInfoParameterResolver løser objekter, der tilhører TestInfo-grænsefladen. Så JUnit 5 vil levere en instans af TestInfo-grænsefladen til enhver metode eller konstruktør, der bruger den.
importerestatisk org.junit.jupiter.api. Påstande.*;
importere org.junit.jupiter.api. Displaynavn;
importere org.junit.jupiter.api. Prøve;
importere org.junit.jupiter.api. TestInfo;klasseInfoTestInterfaceTest{
// Injicere et testInfo-objekt i InfoTestInterfaceTest-konstruktøren
InfoTestInterfaceTest (TestInfo testInfo) {
assertEquals("InfoTestInterfaceTest", testInfo.getDisplayName());
}// Injicere et testInfo-objekt i metoder
@Prøve
ugyldigtestMethodName(TestInfo testInfo){
assertEquals("testMethodName (TestInfo)", testInfo.getDisplayName());
}
@Prøve
@Visningsnavn("metode ved hjælp af @Visningsnavn annotation")
ugyldigtestMetodeNavnTo(TestInfo testInfo){
assertEquals("metode ved hjælp af @Visningsnavn annotation", testInfo.getDisplayName());
}
}
JUnit-testen ovenfor viser, hvordan man injicerer et objekt i en konstruktør og to metoder. Det JUnit TestInfo grænsefladen har fire metoder, som du kan bruge med dets objekt.
Metoden getDisplayName() er den mest nyttige. Det returnerer visningsnavnet på den aktuelle testmetode eller konstruktør. Som standard er dette navn baseret på klassen. Men hvis du bruger @DisplayName-annotationen, vil metoden getDisplayName() returnere denne tekst i stedet.
Testklassen ovenfor genererer følgende testrapport:
Brug DI i @Before og @After Methods
Der er fire andre typer JUnit-annoterede metoder, der understøtter afhængigheder. Disse er @BeforeAll, @BeforeEach, @AfterAll og @AfterEach annoteringerne. Ligesom @Test-metoden er alt, hvad du skal gøre, at sende et objekt til en af før- eller eftermetoderne som en parameter, og du er klar til at gå.
@Før- og @Efter-annoteringerne er vigtige, da de også hjælper dig med at udvikle mere effektiv testkode. At have muligheden for også at injicere afhængigheder i disse metoder vil forbedre din testkode yderligere.