Test som sikkerhedsnet: Refaktorer trygt og sikkert
Test som sikkerhedsnet: Refaktorer trygt og sikkert
At skrive kode er én ting – at ændre den uden at ødelægge noget er en helt anden. Refaktorering handler om at forbedre eksisterende kode uden at ændre dens funktionalitet. Det kan gøre systemet mere overskueligt, hurtigere og lettere at vedligeholde. Men uden et solidt sikkerhedsnet af tests kan selv små ændringer få uforudsete konsekvenser. Her får du en introduktion til, hvordan tests kan give dig ro i maven, når du refaktorerer – og hvordan du bruger dem som et aktivt værktøj i din udviklingsproces.
Hvorfor refaktorere?
Over tid vokser kodebaser. Nye funktioner bliver tilføjet, hurtige løsninger bliver lagt ovenpå gamle, og pludselig er det svært at finde rundt. Refaktorering er den proces, hvor du rydder op i koden: fjerner duplikationer, opdeler store funktioner, giver bedre navne og forbedrer struktur.
Formålet er ikke at ændre, hvad programmet gør, men hvordan det gør det. En velrefaktoreret kodebase er lettere at forstå, teste og udvide – og det sparer tid og frustrationer på sigt.
Men refaktorering kræver mod. For hvad nu, hvis du kommer til at ødelægge noget, der virkede? Det er her, tests kommer ind i billedet.
Test som dit sikkerhedsnet
Forestil dig, at du skal skifte gulvet i et hus, mens folk stadig bor i det. Du vil gerne være sikker på, at huset ikke styrter sammen undervejs. Tests fungerer som de bærende bjælker, der sikrer, at alt stadig står, når du ændrer noget.
Når du har automatiserede tests, kan du hurtigt køre dem efter hver ændring. Hvis noget går galt, får du besked med det samme. Det betyder, at du kan eksperimentere og forbedre koden med langt mindre risiko.
Der findes mange typer tests – enhedstests, integrationstests, end-to-end-tests – men fælles for dem er, at de dokumenterer, hvordan systemet forventes at opføre sig. De bliver dermed både et værktøj til kvalitetssikring og en form for levende dokumentation.
Start med at teste det, der allerede virker
Hvis du står med en ældre kodebase uden tests, kan det virke uoverskueligt at komme i gang. Men du behøver ikke teste alt på én gang. Start med de dele, du oftest ændrer, eller som er mest kritiske for systemets funktion.
En god strategi er at skrive tests, før du refaktorerer. På den måde sikrer du, at du kender den nuværende adfærd, og at du kan opdage, hvis noget ændrer sig utilsigtet. Når du har et grundlæggende testdække, kan du begynde at forbedre koden trin for trin.
Små skridt og hyppige commits
Refaktorering bør ske i små, kontrollerede skridt. Ændr én ting ad gangen, kør tests, og commit, når alt stadig virker. Det gør det nemt at rulle tilbage, hvis noget går galt, og det giver en klar historik over, hvad der er ændret.
Et godt råd er at bruge versionsstyring aktivt. Git gør det nemt at arbejde i separate grene, så du kan eksperimentere uden at påvirke hovedkoden. Når du er tilfreds, kan du merge ændringerne med ro i sindet – velvidende, at dine tests har godkendt dem.
Når testene afslører problemer
Det kan være frustrerende, når en test fejler efter en refaktorering. Men i virkeligheden er det en gave. Det betyder, at testen har fanget en ændring, du måske ikke havde opdaget. I stedet for at se det som en forhindring, kan du se det som en dialog mellem dig og din kode: “Noget er ikke, som det plejer – skal det være sådan?”
Nogle gange afslører tests også, at koden var afhængig af noget, den ikke burde være. Det kan være et tegn på, at du skal justere designet. På den måde hjælper tests dig ikke kun med at finde fejl, men også med at skrive bedre, mere robust kode.
Testdrevet udvikling – et skridt videre
Når du først har oplevet, hvor meget ro tests giver, kan du tage skridtet videre til testdrevet udvikling (TDD). Her skriver du testen, før du skriver koden. Det tvinger dig til at tænke over, hvad koden skal gøre, før du tænker over, hvordan den skal gøre det.
TDD kan virke kunstigt i starten, men mange udviklere oplever, at det fører til mere fokuseret og modulær kode. Samtidig bliver refaktorering en naturlig del af processen, fordi du hele tiden har et sikkerhedsnet, der fortæller dig, om alt stadig virker.
Læs også:
En investering, der betaler sig
At skrive tests tager tid – især i begyndelsen. Men det er en investering, der hurtigt betaler sig. Du sparer tid på fejlfinding, du kan arbejde hurtigere og mere trygt, og du får en kodebase, der er lettere at vedligeholde.
Refaktorering uden tests er som at gå på line uden net. Det kan lade sig gøre, men det kræver nerver af stål. Med tests under dig kan du derimod bevæge dig frit, eksperimentere og forbedre – velvidende, at du bliver grebet, hvis du falder.
Læs også:
