Testdekking is een maat voor hoeveel van je code daadwerkelijk door geautomatiseerde tests wordt gedraaid, meestal weergegeven als percentage. Draaien je tests 800 van de 1.000 regels, dan heb je 80 procent dekking, en lopen de andere 200 regels in productie zonder dat er een test op let.
Een handige vergelijking is een bouwkundige inspectie. Dekking vertelt je welk deel van de kamers de inspecteur echt heeft doorlopen. Tachtig procent gecontroleerd is geruststellend, maar het bewijst niet dat de bekeken kamers grondig zijn nagekeken, en juist in die ongecontroleerde twintig procent kan een nare verrassing schuilen. Dekking werkt net zo: het laat zien waar tests komen, niet hoe goed die tests zijn. Een inspecteur kan door een kamer lopen zonder één kast open te doen. Een test kan een regel code draaien zonder ooit te controleren of die regel het juiste deed. Dus een hoog getal voelt veilig en kan toch hol zijn.
Het hangt nauw samen met je unittests en de test cases erachter. Goed gebruikt is dekking een kompas dat naar risicovolle, ongeteste delen wijst, zodat een team kan beslissen wat meer aandacht verdient. Slecht gebruikt wordt het een getal om mee te sjoemelen, waarbij mensen oppervlakkige tests schrijven om het percentage op te krikken. De kunst is om de gaten als informatie te zien, niet als een score om te verslaan. Een rapport dat laat zien dat de betaallogica nauwelijks getest is, vertelt je precies waar je het volgende uur aan moet besteden, en dat is veel meer waard dan een groen badge op de readme.
Bij TopDevs zien we testdekking als kompas en niet als doel, en richten we tests op de delen van een klantsysteem waar een fout het meeste pijn zou doen, in plaats van een percentage op te blazen dat niets bewijst.
