Refactoring voor testbaarheid
Leer hoe TDD vanzelf tot een beter codeontwerp leidt en hoe u veilig kunt refactoren met vertrouwen in uw tests.
Refactoring voor testbaarheid is een gratis Testen beheersen: JUnit, Mockito en integratietesten-les op CoddyKit. Dit is les 3 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Testen beheersen: JUnit, Mockito en integratietesten. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Testen beheersen: JUnit, Mockito en integratietesten bevat in totaal 4 lessen.
Refactoren in TDD: een introductie
In Test-Driven Development (TDD) is de stap "Refactor" cruciaal. Nadat je een falende test hebt geschreven (Red) en deze hebt laten slagen (Green), gaan we naar de fase Refactor.
Refactoren betekent dat je de interne structuur van code verbetert zonder het externe gedrag ervan te veranderen. Het gaat erom je code schoner, leesbaarder en eenvoudiger te onderhouden te maken.
Het vangnet van tests
Waarom is refactoren veilig in TDD? Omdat je een uitgebreide suite met geslaagde tests hebt!
- Vertrouwen: Je tests fungeren als vangnet en zorgen ervoor dat structurele wijzigingen geen nieuwe fouten introduceren.
- Feedback: Als een test na het refactoren faalt, weet je meteen dat je iets hebt stukgemaakt. Je kunt het dan terugdraaien of herstellen.
Dankzij dit vertrouwen kunnen ontwikkelaars de codekwaliteit voortdurend verbeteren.
Wat is testbare code?
Refactoren leidt vanzelf tot beter testbare code. Maar wat maakt code testbaar?
- Klein en doelgericht: Eenheden code (methoden, klassen) doen één ding goed.
- Losse koppeling: Componenten hebben zo min mogelijk afhankelijkheden van elkaar.
- Duidelijke verantwoordelijkheden: Elke klasse of methode heeft één duidelijk omschreven doel.
Deze principes maken het eenvoudiger om afzonderlijke onderdelen te isoleren en te testen.
Codegeur: verborgen afhankelijkheden
Denk aan een klasse die gegevens verwerkt en ook rechtstreeks berichten naar de console logt. Hierdoor ontstaat een "verborgen afhankelijkheid" van System.out, waardoor het moeilijker wordt om de verwerkingslogica afzonderlijk te testen.
We willen testen of processData werkt, niet of System.out.println werkt!
Voorbeeld: moeilijk testbare code
Hier is een eenvoudige ReportGenerator. Merk op hoe deze rechtstreeks System.out.println gebruikt. Daardoor is het moeilijk om de logica voor het genereren van rapporten te testen zonder console-uitvoer te zien.
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"));
}
}Refactoren: interface extraheren
Om de testbaarheid te verbeteren, kunnen we een interface introduceren voor ons logmechanisme. Hierdoor koppelen we ReportGenerator los van een specifieke implementatie van logging.
Een interface definieert een contract: welke methoden een klasse moet implementeren.
public interface Logger {
void log(String message);
}
public class ConsoleLogger implements Logger {
@Override
public void log(String message) {
System.out.println("Console: " + message);
}
}Refactoren: afhankelijkheidsinjectie
Nu kunnen we de afhankelijkheid Logger in de constructor van ReportGenerator injecteren. Dit heet afhankelijkheidsinjectie.
ReportGenerator maakt zijn logger niet langer zelf aan; de logger wordt eraan doorgegeven. Daardoor kunnen we tijdens het testen veel eenvoudiger een "mock"-logger gebruiken.
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"));
}
}Het voordeel van testbaarheid
Met afhankelijkheidsinjectie wordt testen veel eenvoudiger:
- Je kunt een echte
ConsoleLoggerdoorgeven voor productie. - Voor unittests kun je een testdubbel (zoals een mock) doorgeven die aanroepen registreert zonder echte console-uitvoer. Zo kun je controleren of
logger.log()zoals verwacht is aangeroepen, zonder de testuitvoer te verstoren.
Hierdoor is de logica van je ReportGenerator echt geïsoleerd en testbaar.
Voortdurende verbetering
Refactoren is geen eenmalige gebeurtenis, maar een voortdurende gewoonte binnen de TDD-cyclus. Neem na elke geslaagde test even de tijd om te zoeken naar manieren om de code te verbeteren.
- De padvindersregel: Laat de kampeerplek altijd schoner achter dan je hem aantrof. Pas dit toe op code: laat de module altijd schoner achter dan toen je eraan begon.
Dit leidt tot een codebasis die zich vanzelf ontwikkelt naar een beter ontwerp en hogere kwaliteit.
Controle van de voordelen van refactoren
Denk na over de voordelen van refactoren voor de testbaarheid.
Samenvatting: refactoren voor TDD
In deze les hebben we de cruciale stap "Refactor" in TDD onderzocht. We hebben geleerd dat refactoren, ondersteund door geslaagde tests, ons in staat stelt het ontwerp van code veilig te verbeteren zonder het gedrag te veranderen.
- We hebben gezien hoe refactoren leidt tot beter testbare code door losse koppeling en afhankelijkheidsinjectie te bevorderen.
- Hierdoor kunnen eenheden eenvoudiger worden geïsoleerd voor tests en kunnen testdubbels eenvoudiger worden gebruikt.
- Refactoren is een voortdurend proces dat de codekwaliteit en onderhoudbaarheid in de loop van de tijd verbetert.
Blijf refactoren om robuuste en schone software te bouwen!
Leer Testen beheersen: JUnit, Mockito en integratietesten met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Refactoring voor testbaarheid” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Testen beheersen: JUnit, Mockito en integratietesten, waaronder “Refactoring voor testbaarheid”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Testen beheersen: JUnit, Mockito en integratietesten bevat in totaal 4 lessen.
Wat leer ik in “Refactoring voor testbaarheid”?
Leer hoe TDD vanzelf tot een beter codeontwerp leidt en hoe u veilig kunt refactoren met vertrouwen in uw tests. Je oefent met Testen beheersen: JUnit, Mockito en integratietesten door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Testen beheersen: JUnit, Mockito en integratietesten te beginnen?
Ervaring vooraf is niet nodig. Testen beheersen: JUnit, Mockito en integratietesten op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.
Hoe lang duurt de les “Refactoring voor testbaarheid”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Testen beheersen: JUnit, Mockito en integratietesten?
Ja. Elke les over Testen beheersen: JUnit, Mockito en integratietesten bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Kennismaken met de TDD-cyclus
- Eerst tests schrijven
- Refactoring voor testbaarheid
- De drie wetten van TDD