Refaktorering for testbarhet
Lær hvordan TDD naturlig fører til bedre kodedesign, og hvordan du kan refaktorere trygt med tillit til testene dine.
Refaktorering for testbarhet er en gratis leksjon i Testing i praksis: JUnit, Mockito og integrasjonstester på CoddyKit. Dette er leksjon 3 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Testing i praksis: JUnit, Mockito og integrasjonstester, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Testing i praksis: JUnit, Mockito og integrasjonstester inneholder totalt 4 leksjoner.
Refaktorering i TDD: En introduksjon
I testdrevet utvikling (TDD) er trinnet «Refaktorer» avgjørende. Etter at du har skrevet en test som feiler (rød), og fått den til å bestå (grønn), går du inn i refaktoreringsfasen.
Refaktorering betyr å forbedre den interne strukturen i koden uten å endre den eksterne atferden. Det handler om å gjøre koden renere, mer lesbar og enklere å vedlikeholde.
Testenes sikkerhetsnett
Hvorfor er refaktorering trygt i TDD? Fordi du har en omfattende pakke med tester som består!
- Trygghet: Testene fungerer som et sikkerhetsnett og sikrer at strukturelle endringer ikke introduserer nye feil.
- Tilbakemelding: Hvis en test feiler etter refaktoreringen, vet du umiddelbart at noe er ødelagt, slik at du kan tilbakestille eller rette det.
Denne tryggheten gjør det mulig å forbedre kodekvaliteten kontinuerlig.
Hva er testbar kode?
Refaktorering fører naturlig til mer testbar kode. Men hva gjør kode testbar?
- Liten og fokusert: Kodeenheter (metoder, klasser) gjør én ting godt.
- Løs kobling: Komponentene har få avhengigheter til hverandre.
- Tydelig ansvar: Hver klasse eller metode har ett enkelt, tydelig definert formål.
Disse prinsippene gjør det enklere å isolere og teste enkeltstående deler.
Kodelukt: Skjulte avhengigheter
Tenk på en klasse som behandler data og samtidig logger meldinger direkte til konsollen. Dette innfører en «skjult avhengighet» til System.out, noe som gjør det vanskeligere å teste behandlingslogikken isolert.
Vi vil teste om processData fungerer, ikke om System.out.println fungerer!
Eksempel: Lite testbar kode
Her er en enkel ReportGenerator. Legg merke til at den bruker System.out.println direkte. Dermed blir det vanskelig å teste logikken for rapportgenerering uten å se utskriften 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: Trekk ut et grensesnitt
For å gjøre koden mer testbar kan vi innføre et grensesnitt for loggingsmekanismen. Dette frikobler ReportGenerator fra en bestemt loggingsimplementasjon.
Et grensesnitt definerer en kontrakt: hvilke metoder en klasse må 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: Avhengighetsinjeksjon
Nå kan vi injisere Logger-avhengigheten i konstruktøren til ReportGenerator. Dette kalles Dependency Injection.
ReportGenerator oppretter ikke lenger loggeren selv; den mottar den. Dermed blir det mye enklere å bruke en «mock»-logger under testing.
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 med testbarhet
Med avhengighetsinjeksjon blir testing mye enklere:
- Du kan sende inn en ekte
ConsoleLoggeri produksjon. - I enhetstester kan du sende inn en testdobbel (for eksempel en mock) som registrerer kall uten å skrive ut noe i konsollen. Da kan du kontrollere at
logger.log()ble kalt som forventet, uten å forstyrre testutdataene.
Dette gjør logikken i ReportGenerator virkelig isolert og testbar.
Kontinuerlig forbedring
Refaktorering er ikke en engangshendelse, men en kontinuerlig vane i TDD-syklusen. Etter hver test som består bør du ta deg tid til å se etter måter å forbedre koden på.
- Speiderregelen: Forlat alltid leirplassen ryddigere enn da du fant den. Bruk dette på kode: Forlat alltid modulen ryddigere enn den var da du begynte å arbeide med den.
Dette fører til en kodebase som naturlig utvikler seg mot bedre design og høyere kvalitet.
Sjekk av fordelene ved refaktorering
Vurder fordelene ved refaktorering for å gjøre koden mer testbar.
Oppsummering: Refaktorering for TDD
I denne leksjonen utforsket vi det avgjørende trinnet «Refaktorer» i TDD. Vi lærte at refaktorering, støttet av tester som består, gjør det mulig å forbedre kodedesignet trygt uten å endre atferden.
- Vi så hvordan refaktorering fører til mer testbar kode ved å fremme løs kobling og avhengighetsinjeksjon.
- Dette gjør det enklere å isolere enheter for testing og å bruke testdobler.
- Refaktorering er en kontinuerlig prosess som forbedrer kodekvaliteten og vedlikeholdbarheten over tid.
Fortsett å refaktorere for å bygge robust og ren programvare!
Lær deg Testing i praksis: JUnit, Mockito og integrasjonstester med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «Refaktorering for testbarhet» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Testing i praksis: JUnit, Mockito og integrasjonstester, inkludert «Refaktorering for testbarhet», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Testing i praksis: JUnit, Mockito og integrasjonstester inneholder totalt 4 leksjoner.
Hva lærer jeg i «Refaktorering for testbarhet»?
Lær hvordan TDD naturlig fører til bedre kodedesign, og hvordan du kan refaktorere trygt med tillit til testene dine. Du øver på Testing i praksis: JUnit, Mockito og integrasjonstester med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Testing i praksis: JUnit, Mockito og integrasjonstester?
Ingen tidligere erfaring er nødvendig. Testing i praksis: JUnit, Mockito og integrasjonstester på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «Refaktorering for testbarhet»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Testing i praksis: JUnit, Mockito og integrasjonstester-leksjonen?
Ja. Alle Testing i praksis: JUnit, Mockito og integrasjonstester-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Introduksjon til TDD-syklusen
- Skrive tester først
- Refaktorering for testbarhet
- TDDs tre lover