Testen van code refactoring - is dat nodig en hoe doe je dat?
30 juni 2019 

Testen van code refactoring - is dat nodig en hoe doe je dat?

Testen van code refactoring is een must. Hoe kun je anders weten dat door de refactoring de functionaliteit van de applicatie nog hetzelfde werkt. Het is dan ook van belang dat refactoring gepland wordt uitgevoerd.

Definitie refactoring
Het herstructureren van de code met als doel de leesbaarheid en onderhoudbaarheid te verbeteren en te vereenvoudigen zonder de functionaliteit te veranderen.

Refactoring kan plaatsvinden als gevolg van een code review of technical debt. Het gaat hierbij om kleine wijzigingen en niet het volledig herschrijven van de code.

De ontwikkelaars moeten bij refactoring gebruik maken van unit test. Dat is echter niet voldoende om aan te tonen dat de werking van het systeem niet is gewijzigd. Enerzijds omdat ontwikkelaars soms meer wijzigen dan de kwaliteit en de complexiteit van de code. En anderzijds is de kans aanwezig dat de code op verschillende plekken in de applicatie wordt gebruikt. Er zal daarom ook een functionele regressietest moeten worden uitgevoerd.

Unit test als basis voor refactoring

Het klinkt eenvoudig: gebruik de unit test bij refactoring. Er kunnen zich echter 3 situaties voordoen:

  • Er zijn geen unit tests
  • Unit tests zijn onvolledig of slecht
  • Er zijn unit tests die de afgesproken dekkingsgraad (code coverage) realiseren

Er zijn geen unit tests

Kun je starten met refactoring als er geen unit tests zijn? Nee, dat kan niet. De unit tests zullen alsnog opgesteld moeten worden voorafgaand aan de refactoring. Dit is geen makkelijk taak. Je zult er namelijk achter moeten komen wat de functionaliteit is van de code. Daarna zul je de juiste unit tests moeten maken en uitvoeren. Na het uitvoeren van de refactoring moeten deze unit tests hetzelfde resultaat blijven geven.

Unit tests zijn onvolledig of slecht

Alvorens vast te kunnen stellen of de unit tests onvolledig zijn, zal er vastgesteld moeten worden wat de gewenste dekkingsgraad is. De unit tests zullen daarna eventueel aangevuld moeten worden om de gewenste code coverage te realiseren. Daarna kan begonnen worden met de refactoring.

Unit tests met gewenste code coverage

Dit klinkt als ideaal. Refactoring uitvoeren, unit tests opnieuw uitvoeren en klaar is Kees. Een unit test is echter ook gewoon code. Ook een unit test kan dus refactoring nodig hebben. In deze situatie dien je eerst de unit tests te refractoren en te controleren of de resultaten nog hetzelfde zijn. Daarna kun je beginnen met de refactoring van de code zelf.

Functionele regressietest

Het alleen uitvoeren van unit testen na refactoring is onvoldoende. Unit tests richten zich op kleine stukjes code, maar niet op de context van het systeem. Een functionele regressietest is daarom nodig.

Wat voor het uitvoeren van iedere regressietest geldt, geldt voor refactoring ook. Moet je een volledige regressietest uitvoeren? Het antwoord is afhankelijk van

  • De risico’s
  • De tijd die het kost om een regressietest uit te voeren en de beschikbare tijd
  • Inzicht in de functionaliteit die wordt geraakt door de refactoring
  • Is de regressietest modulair opgezet. Is het makkelijk om delen wel of niet uit te voeren.

Ik zelf geef er de voorkeur aan om een regressietest op te stellen per User story / Use case. En daarbinnen onderscheid te maken tussen testcases voor positief testen en negatief testen. Bij het uitvoeren van de regressietest wordt dan met behulp van parameters aangegeven welke testcases er uitgevoerd moeten worden.

Het komt in de praktijk regelmatig voor dat code hergebruikt wordt voor het realiseren van user stories of use cases. Om te kunnen bepalen wat er meegenomen moet worden in de regressietest is het zaak om daar inzicht in te hebben. En dat is vaak lastige. Developers maken gebruik van versie beheertools, zoals bijvoorbeeld SVN. Bij het inchecken van de code kunnen ze dan een Product Backlog Item nummer (PBI) meegeven. Wanneer dezelfde code nogmaals wordt gebruikt dan is het niet mogelijk of erg lastig om die PBI ook te koppelen aan de code. Een alternatief is het bijhouden van een traceability matrix. Dat is echter wel handwerk en vraagt om discipline.

Samenvattend

Iedere wijziging in de code moet getest worden. En daarom moet er bij refactoring ook getest worden. Unit testen spelen daarbij een belangrijke rol. Vergeet echter de functionele regressietest niet.

Over de schrijver
Ik ben sinds 1983 werkzaam binnen de ICT. Ooit begonnen als Cobol en Credit programmeur en vervolgens de wereld van kwaliteitszorg en testen in gerold. In 1990 ben ik betrokken geweest bij de ontwikkeling van TMap® De jaren daarna heb ik vele functies vervuld binnen het testwerkveld. Waarbij coaching en doceren mij altijd erg is bevallen. Bij Cygnus ben ik met name verantwoordelijk voor het ontwikkelen van content en opleidingen. Heb je een testinhoudelijke vraag of wil je sparren over het stoppen van software fouten bij de bron? Neem dan gerust contact met mij op. Uiteraard ben ik ook beschikbaar voor consultancy opdrachten en coaching.
Reactie plaatsen

arrow_drop_up arrow_drop_down