Een regressietest is een check die je opnieuw draait na een wijziging, om te bevestigen dat iets wat al werkte nog steeds werkt. Het doel is niet de nieuwe functie testen, maar het geval vangen waarin het repareren of toevoegen van één ding stilletjes iets anders breekt.
Stel je voor dat je één kamer in huis verbouwt en daarna door alle andere kamers loopt om te checken dat je geen lichtschakelaar hebt losgetrokken of een deur hebt geblokkeerd. Die rondgang is de regressietest. In software wordt elke test case die je eerder schreef onderdeel van een groeiend vangnet, en veel daarvan zijn kleine unittests die samen draaien. Draai de hele set na een wijziging en je weet binnen minuten of een oude, opgeloste bug is teruggekropen.
Omdat dezelfde checks bij elke release draaien, automatiseren teams ze bijna altijd. Dit met de hand doen op een echt product is traag, en zodra het saai aanvoelt slaat iemand het over en glipt er een bug doorheen.
Een echt voorbeeld: je repareert het kortingscodeveld bij het afrekenen, en een week later worden de verzendkosten niet meer berekend. De twee functies deelden dezelfde afrondingsfunctie voor prijzen, en jouw fix raakte die. Zonder regressieset gaat die wijziging ongemerkt live tot een klant klaagt. Mét een set valt de verzendtest meteen om. Daarmee is de regressietest de stille partner van refactoren, waarbij je code vanbinnen verandert en bewijs nodig hebt dat het gedrag hetzelfde bleef.
In de praktijk groeit de set uit je bughistorie. Telkens als er een echte fout wordt gevonden en opgelost, voegt het team een test toe die hem zou hebben gevangen, zodat diezelfde bug nooit meer ongemerkt terugkomt. Na een paar jaar zijn dat honderden kleine checks, en het draaien kost een paar minuten machinetijd in plaats van een dag handmatig klikken.
Bij TopDevs bouwen we een regressieset op terwijl het product groeit, zodat elke nieuwe release uitkomt zonder de vorige stilletjes ongedaan te maken.
