Definitie
Een unit test is een klein, automatisch uitgevoerd stukje code dat controleert of een specifiek onderdeel van software doet wat het hoort te doen. “Unit” staat voor een afgebakend stuk: een functie, een berekening, een validatieregel. De test draait in milliseconden, geeft groen of rood, en gaat niet over of een gebruiker uiteindelijk tevreden is.
Unit tests zijn een van meerdere testlagen. Naast unit tests bestaan integratietests (werken meerdere onderdelen samen?) en end-to-end tests (werkt het hele proces vanuit gebruikersperspectief?). Samen vormen ze een vangnet waarmee een ontwikkelteam wijzigingen kan doorvoeren zonder bij elke aanpassing alles handmatig na te lopen.
Waarom het ertoe doet voor MKB
Voor een MKB-bedrijf dat software laat bouwen of onderhouden, zijn unit tests een vorm van verzekering. Niet zichtbaar in de demo, wel cruciaal bij de eerste de beste wijziging na oplevering. Software zonder testdekking is alsof een gebouw zonder dragende constructie wordt verbouwd: een aanpassing op één plek kan iets onbedoelds verbreken op een andere plek, en niemand merkt het tot een klant belt.
De ROI zit in de fase na oplevering. Software die maandelijks aanpassingen krijgt, levert zonder tests een groeiende stroom verrassingen op. Met tests blijft het tempo van verbeteren ook na twee jaar nog hoog, omdat een ontwikkelaar binnen seconden weet of een wijziging iets stuk maakt. Dat scheelt facturen.
Concreet voorbeeld
Een SaaS-leverancier voor de bouw had na vijf jaar een platform met tienduizenden regels code en vrijwel geen tests. Elke release leverde gemiddeld drie tot vier nieuwe bugs op die klanten ontdekten, met als gevolg gemiddeld 12 supporturen per week aan brandjes blussen. Releases werden steeds zeldzamer omdat niemand het aandurfde.
Het ontwikkelteam besteedde gedurende vier maanden circa 20% van de tijd aan het toevoegen van unit tests voor de meest gewijzigde modules. Investering: ongeveer €28.000 in werkuren. Na die periode zakten productiebugs naar gemiddeld minder dan één per release, releases liepen van eens per kwartaal naar elke twee weken, en de support-uren daalden met meer dan de helft. De jaarlijkse besparing: ruim €60.000, naast de tevreden klanten en het rustiger nachtleven van de ontwikkelaars.
Misverstanden en valkuilen
- “Tests vertragen het bouwen.” Op korte termijn klopt dat, op langere termijn andersom. Software zonder tests gaat sneller stuk en is duurder om bij te houden. De crossover ligt meestal binnen het eerste jaar van actief onderhoud.
- “100% testdekking is het doel.” Niet zinnig. Hoge dekking voor businesskritische onderdelen, lichte dekking voor randzaken is een betere mix. Sommige code is risico-arm en niet alles loont om te testen.
- “Wij testen handmatig, dat is genoeg.” Handmatig testen schaalt niet. Bij elke release alle oude scenario’s opnieuw uitvoeren kost steeds meer tijd, en uit gewoonte slaan testers stappen over. Automatisering vangt regressies die mensen vergeten.
- “Tests garanderen bug-vrije software.” Tests vangen wat is bedacht om te testen. Onvoorziene fouten en designkwesties komen er door tests niet automatisch uit. Het is een vangnet, geen waarheidsmachine.
Wanneer moet je hiervan wakker liggen, wanneer niet
Wakker liggen: als jouw bedrijf maatwerk-software gebruikt of laat bouwen en niemand kan aantonen of er tests bestaan, of als releases steeds vaker iets onverwachts kapot maken. Bij volwassen software zonder testlaag is technische schuld onzichtbaar maar duur aan het opbouwen, en elke ontwikkelweek voegt risico toe. Een audit van testdekking is meestal de moeite waard.
Niet wakker liggen: als jouw bedrijf alleen standaard SaaS gebruikt, of als de software in kwestie zo eenvoudig en stabiel is dat hij al jaren niet meer wordt aangepast. Testdekking is in dat scenario een academische discussie. Pas zodra er weer ontwikkeld of veranderd wordt, komt het thema terug.
Gerelateerde termen
- CI/CD: automatische pipeline die unit tests bij elke wijziging uitvoert, zodat fouten direct zichtbaar zijn.
- Refactoring: code opschonen lukt veilig dankzij unit tests die controleren of het gedrag onveranderd blijft.
- Technische schuld: gebrek aan tests is een van de meest verraderlijke vormen van opgebouwde schuld in een softwareproject.
- DevOps: werkwijze waarin testen geintegreerd is in de dagelijkse ontwikkel- en releasecyclus.
- Maatwerk software: bij elk maatwerk-traject is het zinvol om afspraken over testdekking vooraf vast te leggen.