Testautomatisering? Houd het simpel

Auteur: Bas Dijkstra ● bas@ontestautomation.com

Redactie: Henk Johan Kwakkel
Komt het volgende scenario je bekend voor?

‘Het begon allemaal zo goed met het inzetten van testautomatisering voor het ondersteunen van onze testactiviteiten. We hebben de tijd genomen voor een grondige toolselectie en goed nagedacht over wat we eigenlijk wilden gaan automatiseren. De eerste maanden liep het allemaal als een zonnetje, en iedereen was tevreden.

Maar op een gegeven moment kwam de klad er een beetje in. De testsuite groeide, het onderhoud ging steeds een beetje meer tijd in beslag nemen, hier en daar begonnen tests te falen. Langzaam maar zeker ebde het vertrouwen en de euforie weg en nu ben ik eigenlijk de enige die af en toe nog wat tijd investeert in het onderhouden van de tests…’

Ik heb in de 14 jaar die ik nu ‘in het vak’ zit in ieder geval al de nodige organisaties en projecten meegemaakt waar het bovenstaande zich heeft afgespeeld. Soms mocht ik komen puinruimen, vaak was ik ook onderdeel van het probleem. Wat begon als een kleine maar waardevolle set van geautomatiseerde tests groeide op den duur uit tot een gigantische verzameling scripts, die:

• veel tijd vroeg om uit te voeren,
• nog meer tijd vroeg om te onderhouden en
• heel veel tijd vroeg om uit te leggen en over te dragen aan anderen (niet iets waar ik achteraf gezien trots op ben, als externe inhuur…)

Hoe komt het nu eigenlijk dat testautomatiseringsprojecten die positief en waardevol beginnen zo vaak uitmonden in een onontwarbare brij van libraries, suites, scripts en code (of low code artifacts)?

Het antwoord? Simpel.

Of beter: een schrijnend gebrek aan simpel.

Er wordt (nogmaals, ook door mij, zeker in het verleden) bij testautomatisering vaak, heel veel tijd besteed aan het toevoegen van nieuwe tests, het uitbreiden van de mogelijkheden van ‘het framework’ en daarmee -hopelijk- aan het verhogen van de testdekking.

Waar we veel minder tijd in lijken te stoppen is in het versimpelen, ontdubbelen, efficiënter maken en opruimen van onze testsuites.

Voor een deel is dat wel te verklaren en zelfs heel menselijk. We vinden het nu eenmaal moeilijk om afscheid te nemen van zaken waar we veel tijd en geld in hebben gestopt om het te creëren. In het Engels is daar zelfs een term voor: ‘sunk cost fallacy’, het doorgaan met een project of activiteit, voornamelijk of alleen omdat er nu eenmaal al zoveel tijd en geld in is gaan zitten.

Maar dat wil niet zeggen dat snoeien in of zelfs weggooien van geautomatiseerde tests een slecht idee is. Integendeel, het is zelfs een heel goed idee en ik zou dan ook graag zien dat we met zijn allen wat meer tijd zouden stoppen in de volgende activiteiten:

• Code reviews op testcode. Wat voor persoon A een waardevolle, leesbare en goed onderhoudbare test lijkt kan voor persoon B kwalitatief veel minder zijn (zeker als persoon A degene is die de test heeft ontwikkeld). Code reviews helpen teams om dit soort onduidelijkheden naar voren te brengen en de kwaliteit van de tests te verhogen. Om code reviews te doen hoeft je de tests trouwens niet in code geschreven te zijn, ze werken ook prima wanneer je met low code testtools werkt.

• Testen van je tests. “Never trust a test you haven’t seen fail” is niet voor niets een vaak gehoorde kreet in testautomatiseringsland. Kan de test die je net hebt gebouwd wel falen? En als deze faalt, is de reden daarvoor dan duidelijk en voor maar één uitleg vatbaar? Een techniek als Mutation testing kan je hierbij helpen, in ieder geval voor je unit tests.

• Opschonen van testsuites. Als ontwikkelaars regelmatig de tijd nemen om applicatiecode te refactoren (en hopelijk doen ze dat…), waarom zouden we dat dan niet doen met geautomatiseerde tests? Die test die je een jaar geleden hebt gebouwd, is die nog steeds waardevol? En hoe zit het met de betrouwbaarheid? Nogmaals, wees niet bang om tests weg te gooien die hun economische levensduur hebben overschreden.

Het uitgangspunt bij al deze activiteiten?

“Houd het simpel”.

Simpele geautomatiseerde tests zijn gestructureerd, leesbaar, controleren bij voorkeur precies één ding en falen alleen om de juiste reden: een potentiële bug in de te testen applicatie. Ook zijn simpele tests beter onderhoudbaar en het kost minder tijd om kennis over simpele tests te delen.

Klinkt allemaal heel mooi, niet? Er is alleen één ding waar we rekening mee moeten houden:

Simpel is niet eenvoudig.

Complexe tests maken is eenvoudig: je neemt een tool, kijkt eens welke features daar allemaal in zitten, gaat nadenken over hoe je die kunt gebruiken om tests te schrijven en een aantal rondjes Google en een StackOverflow later heb je een test die het gewenste resultaat geeft. Of in ieder geval een test die een mooi groen vinkje laat zien.

Heel mooi… Totdat je deze test moet onderhouden na een wijziging in de applicatie, delen van die test wil hergebruiken voor andere tests of de tests onderdeel wil maken van een Continuous Integration-straat die tegen een andere omgeving test.

Simpele geautomatiseerde tests, daarentegen, zijn het resultaat van kritisch nadenken over, onder andere:

• wat wel en niet te automatiseren,
• welke onderdelen en lagen van de applicatie een rol spelen in het verkrijgen van de informatie die de test moet ontsluiten,
• een goed ontwerp van de test en de onderliggende oplossing (het framework), en
• een goede strategie rondom testomgevingen en testdata.

Simpele, elegante tests zijn dan ook vaak het resultaat van lang en hard werken, van continu verbeteren, vereenvoudigen en (niet vergeten!) van weggooien van wat niet werkt. En ja, dat kost tijd, moeite en daarmee geld, en dat vereist specifieke kennis. Ik denk, echter, dat als je op de langere termijn de vruchten wil blijven plukken van testautomatisering, je geen andere keuze hebt dan te streven naar simpele tests.

Of, zoals de Nederlandse software engineer en onderzoeker Edsger Dijkstra het in de jaren ‘80 al verwoordde:

“Elegance is not a dispensable luxury but a quality that decides between success and failure”

Hoe simpel zijn jouw geautomatiseerde tests eigenlijk?