4.1 @Deaktivert
La oss nå se på noen veldig nyttige og populære merknader til JUnit-rammeverket. Den første merknaden lar deg slå av en spesifikk test slik at JUnit ikke kaller den. Det er nødvendig i tilfeller der du merker at testen ikke fungerer som den skal, eller du endrer koden og testen går i stykker ved et uhell.
Som jeg skrev tidligere, støttes ikke 99% av testene av noen, så de viser seg alle å være deaktivert før eller siden. Derfor er denne merknaden den første i listen over nyttige.
Tenk på eksemplet hennes:
public class AppTest {
@Disabled("Test is temporarily disabled. True, true")
@Test
void testOnDev(){
System.setProperty("ENV", "DEV");
Assumptions.assumeFalse("DEV".equals(System.getProperty("ENV")));
}
@Test
void testOnProd(){
System.setProperty("ENV", "PROD");
Assumptions.assumeFalse("DEV".equals(System.getProperty("ENV")));
}
}
I eksemplet ovenfor vil ikke metoden testOnDev()
bli kalt. Forresten, merknaden @Disabled
kan skrives rett før klasseerklæringen, da vil alle metodene bli ignorert.
@Disabled("Temporarily turned off the test, we will fix it by May 2001")
public class AppTest {
@Test
void testOnDev(){
System.setProperty("ENV", "DEV");
Assumptions.assumeFalse("DEV".equals(System.getProperty("ENV")));
}
@Test
void testOnProd(){
System.setProperty("ENV", "PROD");
Assumptions.assumeFalse("DEV".equals(System.getProperty("ENV")));
}
}
4.2 @Nested
JUnit lar deg kalle testmetoder på nestede klasser. Jeg mener nestede testklasser. Det er ikke et faktum at du ofte vil møte dem, men det er en slik mulighet, så du må forstå hva det er.
For å kalle metodene til en nestet klasse før dens erklæring, må du skrive en merknad @Nested
. Eksempel:
public class AppTest {
@Nested
public class DevStagingEnvironment {
@Test
void testOnDev(){
System.setProperty("ENV", "DEV");
Assumptions.assumeFalse("DEV".equals(System.getProperty("ENV")));
}
}
@Nested
public class ProductionEnvironment {
@Test
void testOnProd(){
System.setProperty("ENV", "PROD");
Assumptions.assumeFalse("DEV".equals(System.getProperty("ENV")));
}
}
}
Flere detaljer finner du i den offisielle dokumentasjonen .
4.3 @ExtendWith
En annen nyttig kommentar er @ExtendWith
. Mest sannsynlig vil du møte henne veldig ofte, så la oss se på henne mer detaljert.
JUnit er et kraftig rammeverk som lar deg skrive ulike plugins (utvidelser) for fleksibel tilpasning av arbeidet ditt. Noen utvidelser kan samle inn statistikk om tester, andre kan emulere et filsystem i minnet, andre kan emulere arbeid inne i en webserver, og så videre.
Hvis koden din kjører i et rammeverk (for eksempel Spring), administrerer nesten alltid dette rammeverket opprettelsen og konfigurasjonen av objekter i koden din . Derfor er en spesiell testplugin uunnværlig. Eksempler:
Eksempel 1. Utvidelsen WebServerExtension
går over til den kalte testmetoden URL
for å fungere korrekt.
@Test
@ExtendWith(WebServerExtension.class)
void getProductList(@WebServerUrl String serverUrl) {
WebClient webClient = new WebClient();
// Use WebClient to connect to web server using serverUrl and verify response
assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
}
Dette er hvordan tester vanligvis begynner å teste kode som fungerer med Spring-rammeverket:
@ExtendWith(SpringExtension.class)
@ExtendWith(MockitoExtension.class)
class TestServiceTest {
@MockBean
TestService service;
@Test
void test() {
assertNotNull(service); // Test succeeds
}
}
SpringExtension
lager en testversjon av Spring-rammeverket, men MockitoExtention
lar deg lage falske objekter. Falske gjenstander er et veldig interessant emne, vi vil definitivt berøre det, men litt senere.
4.4 @Timeout
La oss avslutte denne forelesningen med en liten og interessant kommentar @Timeout
. Den lar deg stille inn tiden for å kjøre testen. Hvis testen tok mer tid enn angitt i merknaden, anses den som mislykket.
class TimeoutDemo {
@Test
@Timeout(value = 100, unit = TimeUnit.MILLISECONDS)
void failsIfExecutionTimeExceeds100Milliseconds() {
// test will fail if it takes more than 100 milliseconds
}
}
Dette avslutter foredraget vårt.