Refaktorering med fokus på testbarhed
Lær, hvordan TDD naturligt fører til bedre kodedesign, og hvordan du refaktorerer sikkert med tillid til dine tests.
Refaktorering med fokus på testbarhed er en gratis Mestrer test: JUnit, Mockito og integrationstest-lektion på CoddyKit. Dette er lektion 3 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.
Refaktorering i TDD: En introduktion
I testdrevet udvikling (TDD) er trinnet »Refaktorér« afgørende. Når du har skrevet en fejlslagen test (rød) og fået den til at bestå (grøn), går du ind i refaktoreringens fase.
Refaktorering betyder, at du forbedrer kodens interne struktur uden at ændre dens eksterne adfærd. Det handler om at gøre koden renere, mere læsbar og lettere at vedligeholde.
Testenes sikkerhedsnet
Hvorfor er refaktorering sikker i TDD? Fordi du har en omfattende samling af tests, der består!
- Sikkerhed: Dine tests fungerer som et sikkerhedsnet og sikrer, at de strukturelle ændringer, du foretager, ikke introducerer nye fejl.
- Feedback: Hvis en test fejler efter refaktorering, ved du med det samme, at noget er gået i stykker, så du kan rulle ændringen tilbage eller rette den.
Denne sikkerhed gør det muligt for udviklere løbende at forbedre kodekvaliteten.
Hvad er kode, der kan testes?
Refaktorering fører naturligt til kode, der er lettere at teste. Men hvad gør kode testbar?
- Lille og fokuseret: Kodeenheder (metoder, klasser) gør én ting godt.
- Løs kobling: Komponenterne har kun få afhængigheder af hinanden.
- Klare ansvarsområder: Hver klasse eller metode har ét klart defineret formål.
Disse principper gør det lettere at isolere og teste de enkelte dele.
Kodelugt: Skjulte afhængigheder
Forestil dig en klasse, der behandler data og samtidig logger meddelelser direkte til konsollen. Det introducerer en »skjult afhængighed« af System.out, hvilket gør det sværere at teste behandlingslogikken isoleret.
Vi vil teste, om processData fungerer, ikke om System.out.println fungerer!
Eksempel: Kode, der er svær at teste
Her er en enkel ReportGenerator. Bemærk, hvordan den bruger System.out.println direkte. Det gør det svært at teste logikken til generering af rapporter uden at se output i konsollen.
public class ReportGenerator {
public String generateReport(String data) {
// Simulate some complex processing
String processedData = "Processed: " + data.toUpperCase();
System.out.println("Log: Report generated for " + data);
return processedData;
}
public static void main(String[] args) {
ReportGenerator generator = new ReportGenerator();
System.out.println(generator.generateReport("sales"));
}
}Refaktorering: Udtræk en grænseflade
For at gøre koden lettere at teste kan vi introducere en grænseflade til vores mekanisme til logning. Det afkobler ReportGenerator fra en bestemt implementering af logning.
En grænseflade definerer en kontrakt: hvilke metoder en klasse skal implementere.
public interface Logger {
void log(String message);
}
public class ConsoleLogger implements Logger {
@Override
public void log(String message) {
System.out.println("Console: " + message);
}
}Refaktorering: Afhængighedsinjektion
Nu kan vi injicere afhængigheden Logger i konstruktøren til ReportGenerator. Det kaldes afhængighedsinjektion.
ReportGenerator opretter ikke længere sin logger; den modtager den. Det gør det meget lettere at levere en »mock«-logger under test.
public interface Logger {
void log(String message);
}
public class ConsoleLogger implements Logger {
@Override
public void log(String message) {
System.out.println("Console: " + message);
}
}
public class ReportGenerator {
private final Logger logger;
public ReportGenerator(Logger logger) {
this.logger = logger;
}
public String generateReport(String data) {
String processedData = "Processed: " + data.toUpperCase();
logger.log("Report generated for " + data);
return processedData;
}
public static void main(String[] args) {
Logger consoleLogger = new ConsoleLogger();
ReportGenerator generator = new ReportGenerator(consoleLogger);
System.out.println(generator.generateReport("sales"));
}
}Fordelen ved testbarhed
Med afhængighedsinjektion bliver testning meget enklere:
- Du kan videregive en rigtig
ConsoleLoggeri produktion. - Til enhedstests kan du videregive en testdobbelt (for eksempel en mock), der registrerer kald uden faktisk output i konsollen. Det gør det muligt at kontrollere, at
logger.log()blev kaldt som forventet, uden at påvirke testoutputtet.
Det gør logikken i din ReportGenerator virkelig isoleret og testbar.
Løbende forbedring
Refaktorering er ikke en engangsforeteelse; det er en løbende vane i TDD-cyklussen. Efter hver test, der består, bør du bruge et øjeblik på at se efter måder at forbedre koden på.
- Spejderreglen: Efterlad altid lejrpladsen renere, end da du fandt den. Anvend det på kode: Efterlad altid modulet renere, end da du begyndte at arbejde på det.
Det fører til en kodebase, der naturligt udvikler sig mod bedre design og højere kvalitet.
Tjek af fordelene ved refaktorering
Overvej fordelene ved refaktorering for at gøre koden lettere at teste.
Opsummering: Refaktorering i TDD
I denne lektion gennemgik vi det afgørende trin »Refaktorér« i TDD. Vi lærte, at refaktorering, der understøttes af tests, som består, gør det muligt at forbedre kodens design sikkert uden at ændre dens adfærd.
- Vi så, hvordan refaktorering fører til mere testbar kode ved at fremme løs kobling og afhængighedsinjektion.
- Det gør det lettere at isolere enheder til test og enklere at bruge testdoubler.
- Refaktorering er en løbende proces, der forbedrer kodekvaliteten og vedligeholdbarheden over tid.
Bliv ved med at refaktorere for at bygge robust og ren software!
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 “Refaktorering med fokus på testbarhed” gratis?
Ja — alle 3 lektioner i læringssporet Mestrer test: JUnit, Mockito og integrationstest, inklusive “Refaktorering med fokus på testbarhed”, 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 “Refaktorering med fokus på testbarhed”?
Lær, hvordan TDD naturligt fører til bedre kodedesign, og hvordan du refaktorerer sikkert med tillid til dine tests. 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 3 af 4.
Hvor lang tid tager lektionen “Refaktorering med fokus på testbarhed”?
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
- Introduktion til TDD-cyklussen
- Skriv tests først
- Refaktorering med fokus på testbarhed
- TDD's tre love