Testlivscyklus og rækkefølge
Styr rækkefølgen for testkørsel, og håndtér opsætning og nedlukning af tests med avancerede livscyklusannotations.
Testlivscyklus og rækkefølge er en gratis Mestrer test: JUnit, Mockito og integrationstest-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Mestrer test: JUnit, Mockito og integrationstest, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Mestrer test: JUnit, Mockito og integrationstest-kurset indeholder 4 lektioner i alt.
Introduktion til JUnit-testenes livscyklus
Velkommen! I denne lektion dykker vi ned i avancerede funktioner i JUnit 5, som giver dig kontrol over, hvordan dine test køres. Det er vigtigt at forstå testenes livscyklus, når du skal håndtere ressourcer og sikre korrekt opsætning og oprydning.
Livscyklussen definerer rækkefølgen af handlinger, som JUnit udfører før og efter dine testmetoder og klasser.
Opsætning på klasseniveau: @BeforeAll
Nogle gange har du brug for kun at udføre opsætningshandlinger én gang for alle test i en bestemt testklasse. Annoteringen @BeforeAll markerer en metode, der skal køre før en testmetode i klassen.
Som standard skal @BeforeAll-metoder være static. Om lidt ser du, hvordan det ændres!
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class BeforeAllDemo {
private static StringBuilder log = new StringBuilder();
@BeforeAll
static void setupOnce() {
log.append("-> @BeforeAll: Setup done once.\n");
System.out.println("Setup for all tests.");
}
@Test
void testA() {
log.append(" -> @Test: Running testA.\n");
System.out.println(" Running testA.");
assertTrue(true);
}
@Test
void testB() {
log.append(" -> @Test: Running testB.\n");
System.out.println(" Running testB.");
assertTrue(true);
}
// The log output would typically be verified in @AfterAll or debugger.
}Oprydning på klasseniveau: @AfterAll
Tilsvarende kan du have brug for at rydde ressourcer op én gang, efter alle test i en klasse er afsluttet. Annoteringen @AfterAll markerer en metode, der skal køre efter alle testmetoder i klassen.
Ligesom @BeforeAll skal den som standard være static.
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class AfterAllDemo {
private static StringBuilder log = new StringBuilder();
@BeforeAll
static void setup() {
log.append("-> @BeforeAll: Setup for AfterAllDemo.\n");
}
@Test
void testOne() {
log.append(" -> @Test: Running testOne.\n");
assertTrue(true);
}
@Test
void testTwo() {
log.append(" -> @Test: Running testTwo.\n");
assertTrue(true);
}
@AfterAll
static void teardown() {
log.append("-> @AfterAll: Teardown for AfterAllDemo.\n");
System.out.println("--- Execution Log ---");
System.out.println(log.toString()); // See the full order
System.out.println("--- End Log ---");
}
}@TestInstance: PER_CLASS-livscyklus
Som standard opretter JUnit en ny instans af din testklasse for hver testmetode (Lifecycle.PER_METHOD). Det sikrer, at testene er isolerede.
Hvis du har brug for, at @BeforeAll- og @AfterAll-metoder ikke er statiske, eller hvis du vil dele tilstand mellem alle test i en klasse, kan du skifte testinstansens livscyklus til Lifecycle.PER_CLASS.
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.TestInstance.Lifecycle;
import static org.junit.jupiter.api.Assertions.assertEquals;
@TestInstance(Lifecycle.PER_CLASS) // Allows non-static @BeforeAll/@AfterAll
public class PerClassLifecycleDemo {
private int counter = 0; // Instance variable, shared across tests
@BeforeAll // No longer needs to be static!
void setupPerClass() {
counter = 10;
System.out.println("-> @BeforeAll (PER_CLASS). Counter: " + counter);
}
@Test
void testIncrementOne() {
counter++;
System.out.println(" -> @Test 1. Counter: " + counter);
assertEquals(11, counter); // Shared state is modified
}
@Test
void testIncrementTwo() {
counter++;
System.out.println(" -> @Test 2. Counter: " + counter);
assertEquals(12, counter); // Counter continues from previous test
}
@AfterAll // No longer needs to be static!
void teardownPerClass() {
System.out.println("-> @AfterAll (PER_CLASS). Final Counter: " + counter);
}
}Hvornår skal test rækkefølges?
Ideelt set bør JUnit-test være uafhængige og køre korrekt i enhver rækkefølge. Hvis du er afhængig af en bestemt rækkefølge, kan dine test blive skrøbelige og sværere at vedligeholde.
Der findes dog bestemte situationer, hvor en eksplicit rækkefølge kan være nyttig:
- Test af et komplekst arbejdsforløb med tydelige, sekventielle trin.
- Optimering af ydeevnen ved at gruppere hurtige test eller test med fælles, kostbar opsætning.
- Arbejde med ældre systemer, der kræver en bestemt rækkefølge af interaktioner.
@TestMethodOrder-annotering
Hvis du vil definere en kørselsrækkefølge for testmetoder i en klasse, bruger du annoteringen @TestMethodOrder på klasseniveau. Den tager en implementering af MethodOrderer som argument.
JUnit 5 har flere indbyggede strategier:
Alphanumeric.class: Sorterer efter metodenavne i alfabetisk rækkefølge.OrderAnnotation.class: Bruger annoteringen@Order.Random.class: Gør rækkefølgen tilfældig.DisplayName.class: Sorterer efter metodernes viste navne.
Alfanumerisk metoderækkefølge
Lad os se MethodOrderer.Alphanumeric.class i praksis. JUnit sorterer ganske enkelt testmetoderne efter deres navne i alfabetisk rækkefølge.
Det er en enkel måde at få en forudsigelig rækkefølge på, hvis dine metodenavne naturligt følger en sekvens.
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;
import org.junit.jupiter.api.MethodOrderer.Alphanumeric;
import static org.junit.jupiter.api.Assertions.assertTrue;
@TestMethodOrder(Alphanumeric.class) // Tests run A, B, C
public class AlphanumericOrderDemo {
@Test
void testA_First() {
System.out.println("-> Running testA_First");
assertTrue(true);
}
@Test
void testC_Third() {
System.out.println("-> Running testC_Third");
assertTrue(true);
}
@Test
void testB_Second() {
System.out.println("-> Running testB_Second");
assertTrue(true);
}
}Tilpasset rækkefølge med @Order
Hvis du vil have detaljeret kontrol, kan du kombinere @TestMethodOrder(MethodOrderer.OrderAnnotation.class) med annoteringen @Order(value) på de enkelte testmetoder. Lavere value-tal betyder tidligere kørsel.
På den måde kan du definere en præcis, tilpasset rækkefølge for dine test.
import org.junit.jupiter.api.Order;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;
import org.junit.jupiter.api.MethodOrderer.OrderAnnotation;
import static org.junit.jupiter.api.Assertions.assertTrue;
@TestMethodOrder(OrderAnnotation.class) // Activate @Order annotation
public class CustomOrderDemo {
@Test
@Order(2) // This test runs second
void processStepTwo() {
System.out.println("-> Running processStepTwo");
assertTrue(true);
}
@Test
@Order(1) // This test runs first
void initializeSystem() {
System.out.println("-> Running initializeSystem");
assertTrue(true);
}
@Test
@Order(3) // This test runs third
void finalizeReport() {
System.out.println("-> Running finalizeReport");
assertTrue(true);
}
}Bedste praksis for rækkefølge
Selvom eksplicit rækkefølge er effektiv, bør den bruges med omtanke:
- Prioritér uafhængighed: Hver test bør helst kunne køre alene.
- Læsevenlighed: For meget rækkefølgestyring kan gøre test sværere at forstå og vedligeholde.
- Vedligeholdelsesbyrde: Ændringer i systemet kan kræve, at du vurderer og opdaterer rækkefølgeværdierne.
Brug kun rækkefølgestyring, når der er en stærk og velbegrundet årsag, og foretræk @Order for at gøre hensigten tydelig.
Tjek af livscyklus og rækkefølge
Se på følgende JUnit 5-testklasse:
import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.assertEquals;
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
public class QuizTest {
private int sharedValue = 0;
@BeforeAll
void setup() {
sharedValue = 10;
System.out.println("BeforeAll: sharedValue = " + sharedValue);
}
@Test
@Order(2)
void testB() {
sharedValue += 2;
System.out.println(" TestB: sharedValue = " + sharedValue);
assertEquals(13, sharedValue);
}
@Test
@Order(1)
void testA() {
sharedValue += 1;
System.out.println(" TestA: sharedValue = " + sharedValue);
assertEquals(11, sharedValue);
}
@AfterAll
void teardown() {
System.out.println("AfterAll: sharedValue = " + sharedValue);
}
}Hvad bliver den endelige værdi af sharedValue, der udskrives i metoden @AfterAll?
Opsummering: Livscyklus og rækkefølge
I denne lektion har du lært avancerede funktioner i JUnit 5 til at styre testkørslen:
- Livscyklus på klasseniveau:
@BeforeAllog@AfterAlltil opsætning og oprydning én gang. - Instansens livscyklus:
@TestInstance(Lifecycle.PER_CLASS)for at aktivere delt tilstand og ikke-statiske kroge på klasseniveau. - Rækkefølge for testmetoder:
@TestMethodOrder(med strategier somAlphanumericellerOrderAnnotation) til at definere kørselsrækkefølgen. - Tilpasset rækkefølge:
@Orderfor præcis kontrol over metodernes rækkefølge.
Husk at bruge eksplicit rækkefølge med omtanke og prioritere uafhængige og robuste test!
Lær Mestrer test: JUnit, Mockito og integrationstest med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Testlivscyklus og rækkefølge” gratis?
Ja — alle 3 lektioner i læringssporet Mestrer test: JUnit, Mockito og integrationstest, inklusive “Testlivscyklus og rækkefølge”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Mestrer test: JUnit, Mockito og integrationstest-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Testlivscyklus og rækkefølge”?
Styr rækkefølgen for testkørsel, og håndtér opsætning og nedlukning af tests med avancerede livscyklusannotations. Du øver dig i Mestrer test: JUnit, Mockito og integrationstest med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Mestrer test: JUnit, Mockito og integrationstest?
Der kræves ingen tidligere erfaring. Mestrer test: JUnit, Mockito og integrationstest på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.
Hvor lang tid tager lektionen “Testlivscyklus og rækkefølge”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Mestrer test: JUnit, Mockito og integrationstest-lektion?
Ja. Alle Mestrer test: JUnit, Mockito og integrationstest-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Testlivscyklus og rækkefølge
- Parametriserede og dynamiske tests
- Test af exceptions og timeouts
- Betingede tests og assumptions