Redactie: Henk Johan Kwakkel
Auteur: Bas Dijkstra, OnTestAutomation ● bas@ontestautomation.com
Of je nu gebruikmaakt van codegebaseerde tools (zoals bijvoorbeeld Selenium WebDriver of REST Assured) of van ‘low code’ of ‘no code’ oplossingen, testautomatisering is een vorm van softwareontwikkeling.
Dat betekent dat je bij de implementatie van de software, net zoals je (hopelijk!) voor je productiecode doet, rekening moet houden met de kwaliteit en de onderhoudbaarheid. Patronen en principes die veel worden gebruikt in reguliere softwareontwikkeling voor het verbeteren van die software, kunnen ook worden toegepast wanneer je tests aan het automatiseren bent. Ter illustratie twee voorbeelden.
Encapsulatie en Page Objects
Object-georiënteerd programmeren kent vier ‘pilaren’, concepten die worden toegepast om code te kunnen structureren en complexiteit terug te brengen: encapsulatie, abstractie, overerving en polymorfisme. Als voorbeeld nemen we hier encapsulatie (‘inkapselen’): het toegang geven tot eigenschappen van een klasse via accessor-methoden (‘getters’) en mutator-methoden (‘setters’). Gebruik van encapsulatie stelt een ontwikkelaar in staat om een object van een bepaalde klasse te gebruiken zonder zich druk te hoeven maken over hoe die klasse precies is geïmplementeerd.
Een bekend en veelgebruikt patroon voor het onderhoudbaar maken van Selenium WebDriver-tests is het Page Object-patroon PageObjects. Page Objects zijn een toepassing van encapsulatie: een tester die een test schrijft met objecten op een bepaalde pagina kan gebruikmaken van het Page Object dat deze pagina representeert en de acties die daarin zijn gedefinieerd, zonder dat ze zich druk hoeven te maken over hoe dat Page Object precies is geïmplementeerd.
Don’t Repeat Yourself
Het DRY-principe suggereert dat je jezelf als ontwikkelaar niet moet herhalen: wanneer je dezelfde instructies meerdere keren nodig hebt op twee verschillende plekken in je codebase, stelt DRY voor dat je deze code verplaatst naar een eigen (helper-)methode. Ook voor testcode is dit een goed idee: wanneer je in meerdere tests dezelfde code gebruikt om een bepaalde actie uit te voeren, of op meerdere plaatsen in je Selenium-code bijvoorbeeld dezelfde locators gebruikt, is het waarschijnlijk een goed idee om die code naar een centrale plek te verhuizen (zoals een Page Object). Dit komt de onderhoudbaarheid ten goede.
Zomaar even twee voorbeelden om aan te geven dat het toepassen van patronen en principes ook een goed idee is als je aan testautomatisering werkt. Je kunt er echter ook in doorslaan…
Yes, automation development equals software development. That doesn’t mean you need to cram every single software development pattern, abstraction technique and polymorphic encapsuheritance paradigma known to man in your ‘framework’. FFS.
— Bas Dijkstra (@_basdijkstra) 18 september 2018
Waar het consequent voorrang geven aan onderhoudbaarheid bij productiecode vaak een goed idee is, betwijfel ik of we daar bij het schrijven van testcode wel zo goed aan doen. Natuurlijk, testcode moet goed onderhoudbaar zijn, maar daarnaast is leesbaarheid vaak minimaal net zo belangrijk, zo niet nog belangrijker. Goed leesbare code is eenvoudiger te begrijpen, ook voor mensen die die code misschien niet zouden kunnen schrijven. Goed leesbare code documenteert zichzelf tot op zekere hoogte. Dat maakt het weer makkelijker om te kunnen communiceren over wat de code nu eigenlijk doet (en dus wat ermee wordt getest), en daarom denk ik dat te ver doorslaan in het optimaliseren van je testcode niet altijd een goed idee is.
Niets ten nadele van ontwikkelaars (zonder ontwikkelaars zouden wij als testers geen werk hebben…), maar het is vaak wel te zien aan een ‘framework’ voor testautomatisering of deze door een ontwikkelaar of door (of in ieder geval in samenwerking met) een tester is opgezet. Ik heb te vaak meegemaakt dat een ontwikkelaar de opdracht kreeg of op zich had genomen om een framework te maken. Zodra ‘de tests erin gebouwd moesten worden’ vond de ontwikkelaar dat het werk klaar was en dat de testers de tests erin moesten bouwen.
![](https://www.testnet.org/wp-content/uploads/2018/03/cranium-2099119_1280-1.png")
Als je als tester niet al vanaf het begin betrokken bent bij de opzet van een testautomatiseringsoplossing – ik zeg niet dat je alles zelf moet schrijven, ontwikkelaars zijn gemiddeld genomen nou eenmaal beter in het schrijven van code… – is het gevaar dat je wordt opgezadeld met een oplossing die misschien prima werkt, maar nodeloos complex is en niet uitblinkt in wat het zou moeten doen, namelijk ondersteunen bij het uitvoeren van je testactiviteiten.
Want dat is wat testautomatisering uiteindelijk is: een manier om testen te ondersteunen. Geen vervanging van testers, geen doel op zich, maar een hulpmiddel dat je in staat stelt efficiënter je werk te doen. Dat betekent dat je dat ook in je achterhoofd moet houden als je je bezighoudt met het opzetten van testautomatisering. Houd altijd in de gaten voor wie het is bedoeld, wie er mee gaat werken en wat hun vaardigheden zijn.
En misschien betekent dat wel dat testautomatiseringscode niet tot in de puntjes geoptimaliseerd is. Dat leesbaarheid boven onderhoudbaarheid gaat of dat je hier en daar codeduplicatie hebt. Als dat ten goede komt aan de leesbaarheid en bruikbaarheid van je testautomatisering zou ik zeggen: gá ervoor.
Of, zoals Michael Lynch het recent in dit artikel Good developers, bad tests verwoordde: ‘Good production code is well-factored; good test code is obvious’. Helemaal mee eens.