644 tests, en waarom dat getal ertoe doet

Aan het eind van een lange werkdag stond de teller op 644 tests die slaagden. Een mooi getal om naar te kijken. Maar het getal zelf is niet het punt. Het punt is wat die tests doen op een dag dat ik moe ben, haast heb, of iets over het hoofd zie.

Dit is een soloproject. Er is geen collega die mijn werk nakijkt, geen team dat aan de bel trekt als ik een fout maak. En het systeem gaat straks handelen met echt geld. Die twee dingen samen, alleen werken en geld op het spel, maken een testsuite geen luxe maar een noodzaak.

Wat tests vervangen

In een normaal team heb je mensen om je heen die fouten opvangen. Iemand die in een review zegt "wacht, hiermee breekt dat andere ding". Die laag ontbreekt als je alleen werkt. Tests zijn de vervanging daarvan. Ze zijn het collectieve geheugen van alle fouten die ooit zijn gemaakt en opgelost, vastgelegd zodat ze niet opnieuw kunnen sluipen.

Elke keer dat er een bug werd gevonden en opgelost, kwam er een test bij die precies die situatie afdekt. Niet om het getal op te hogen, maar zodat die specifieke fout nooit meer ongemerkt terug kan komen. Een bug die je een keer hebt gehad en gerepareerd, wil je niet over een maand per ongeluk opnieuw introduceren omdat je iets anders aanpaste.

Zo groeit een testsuite vanzelf. Niet door vooraf 644 tests te bedenken, maar door elke fout om te zetten in een vangnet. Het getal is een bijproduct van die gewoonte, niet het doel.

De test die de echte fout beschrijft

Het mooiste soort test is er een die een fout vastlegt die je daadwerkelijk hebt gehad. Toen er deze week een bug opdook waarbij het systeem een verkeerde administratie-regel kon raken, werd niet alleen de fout opgelost. Er kwam een test bij die exact dat scenario nabootst: precies de situatie die misging, met de verwachting dat het nu goed gaat.

Dat is meer waard dan honderd algemene tests. Want als iemand ooit die oplossing per ongeluk terugdraait, springt die ene test meteen op rood. De fout van vandaag kan de fout van over een half jaar niet meer worden.

Datzelfde gold voor een correctie aan de boekhouding van het systeem. De kern van die fix was dat hij de posities met rust moest laten, want die klopten al. De belangrijkste test was niet of de correctie werkte, maar of de posities daarna nog exact hetzelfde waren. Die test bewijst wat de fix niet mag doen. Soms is dat belangrijker dan bewijzen wat hij wel doet.

Tests als toestemming om door te werken

Er is nog een reden waarom dit getal me iets doet. Het geeft me toestemming om door te werken zonder bang te zijn.

Als ik iets aanpas en daarna draaien alle tests groen, weet ik dat ik niet per ongeluk iets anders heb gebroken. Dat klinkt klein, maar het is het verschil tussen voorzichtig vooruit durven en verlamd zijn van twijfel. Zonder dat vangnet zou elke wijziging een gok zijn. Met dat vangnet wordt elke wijziging een gecontroleerde stap.

Juist als je alleen werkt is dat onbetaalbaar. Niemand anders bevestigt dat het nog werkt. De tests doen dat, elke keer, in seconden.

Wat dit me leerde

Een testsuite is geen bewijs dat je code perfect is. Tests vangen alleen wat je hebt bedacht om te testen, en er is altijd iets wat je niet hebt voorzien. Maar voor een systeem dat met geld gaat draaien, gebouwd door één persoon, is het de dichtstbijzijnde vervanging voor een team dat over je schouder meekijkt.

Het getal 644 zegt niet "dit systeem is foutloos". Het zegt "644 keer is er iets vastgelegd dat niet meer stilletjes kapot kan". Dat is een heel ander soort vertrouwen, en een eerlijker soort.

Bouw geen tests om een getal te halen. Bouw ze zodat elke fout die je een keer hebt gehad, nooit meer een verrassing kan zijn.