Automatische tests

Eerder schreef ik al wat over technische schuld. Het niet hebben van automatische tests wordt vaak beschouwd als een technische schuld.

Wat zijn automatische tests?

Testen doe je om er zeker van te zijn dat iets werkt dat het goed werkt. Automatische testen maak je (of laat je maken) omdat zeker weten dat het goed werkt veel tijd kost. Wanneer je applicatie vaak nog wordt veranderd wil je er immers ook zeker van zijn dat het ook blijft werken. Automatische tests zijn kleine programmaatjes die testen of onderdelen onafhankelijk (unit-tests) of in samenhang (integratie-tests) goed werken.

Integratie- en unittesten

Bij unit-testen worden kleine onderdelen afzonderlijk bekeken of ze nog werken. Zo kan bijvoorbeeld steeds worden gecontroleerd of de bedragen in een offerte wel nog steeds netjes worden opgeteld, en een andere of er nog wel het verwachtte btw bedrag uit blijft komen.

Bij integratie-toetsen, of systeem-toetsen, wordt er automatisch door de applicatie geklikt en getypt en wordt er gecontroleerd of de verwachtte tekst wel op de juiste plek staat. Bijvoorbeeld: krijg je na het inloggen wel de juiste pagina te zien, en opent de factuur wanneer je er op klikt?

Kun je zonder?

Als er gebruik wordt gemaakt van een standaard pakket (of een framework) en je blijft grotendeels binnen de kaders van dit standaard pakket, dan is de kans op grote fouten een stuk minder. Veel gedragingen zijn dan nl. gestandaardiseerd, en worden al elders getest. Daarnaast helpt een framework bij het structureren van een applicatie waarmee de noodzaak van grote architectuurwijzigingen waarschijnlijk lager is en/of anders is het risico beheersbaarder. Let echter wel op dat dit een aanname is. Een nieuwe versie van het framework, waar je noodzakelijkerwijs mogelijk naar moet upgraden omdat de oudere versie niet meer voorzien wordt van veiligheidsupdates kan zeker risico’s met zich meebrengen. Je kunt er echter best voor kiezen om de applicatie dan toch handmatig door te testen. Niet alle applicaties bestaan uit tig schermen. En misschien wil je sowieso weten of de layout nog wel helemaal in elkaar steekt zoals je verwacht.

Je kunt er ook voor kiezen om te accepteren dat de applicatie soms gewoon stuk live wordt gezet: “Move Fast and Break Things.” was een oud Facebook adagium. Testen in productie is mijns inziens echter geen vervanger voor een goede snel draaiende testsuite. Je kunt weliswaar de keuze maken om te accepteren dát er soms dingen mis gaan en je daarop voorbereiden, maar ad hoc problemen oplossen in productie levert vaak stress en lage kwaliteit oplossingen op.

Terzijde: Blijven meten?

Je kunt blijven meten of er gekke dingen gebeuren: Zoekt ineens niemand meer in je applicatie? Worden er geen berichten gestuurd? Krijg je een exceptie terug in je monitoringssysteem? Wanneer je snel reageert kan de groep die er last van heeft beperkt blijven. Op een zekere schaal kun je er zelfs voor kiezen slechts een paar procent van de gebruikers de nieuwe versie voor te schotelen als een ‘experiment’. Het is echter altijd aan te bevelen te meten wat er gebeurd op productie. Hoe goed je het ook voorbereid, een productieomgeving wijkt bijna altijd af van een test (en staging) omgeving.

Kwantiteit versus kwaliteit

Laat je niet blind staren op getallen. Een test coverage van nabij de 100% klinkt erg goed, maar kwantiteit is niet per definitie kwaliteit. Een goede test is sceptisch als een wetenschapper over de uitkomst van een experiment. Maar het percentage “test coverage” is slechts een uitspraak over het percentage regels dat is aangeroepen gedurende het uitvoeren van de tests. Een test die slechts aanroept en niet verschillende aanroepen en de bijbehorende uitkomsten controleert laat de test coverage snel oplopen, maar zegt weinig. Al zou je kunnen zeggen dat de ‘happy flow’ werkt.

Breng risico’s in kaart

Als je niet de tijd hebt om uitgebreid tests te schrijven, breng dan in ieder geval de risico’s goed in kaart. Sommige dingen blijven echt wel werken. Maar een niet ingelogde gebruiker die toch zaken kan aanpassen in je ietwat aparte workflow? Niet bepaald wenselijk gedrag en voor het bedenken van een automatisch test is weinig creativiteit vereist.

Kosten

Er zijn programmeurs die claimen dat het niets kost. Dat is uiteindelijk waar. Vandaar dat gebrek aan automatische tests wordt geplaatst in de hoek van technische schuld. Op een gegeven moment gaat het hebben ervan zelfs geld opleveren. Want fouten vinden die een probleem veroorzaken kost relatief veel tijd. Code, of zelfs een programma, begint echter soms als een experiment. Een nieuwe functie, die mogelijk nog op een andere manier geïmplementeerd gaat worden. Het hangt af van de risico’s en de complexiteit van de code die hiervoor nodig is of het dan de moeite waard is. Je mag best pragmatisch blijven. Zolang je de schuld maar inlost. En, niet alle schuld is gelijk.

Public domain image by the National Cancer Institute. More information on Wikipedia Commons