Ondertussen alweer een jaar geleden waren we bij de SeleniumConf in Londen. De conferenties beginnen virtueel weer een beetje op te starten, maar wat niet iedereen weet, is dat de talks van vorig jaar ook op YouTube te vinden zijn. Daarom nu een blog over de video van Aditi Mulay op SeleniumConf 2019. De titel? “Build an automation framework… with a developers mindset”. Wil jij hem ook kijken? Kijk dan onderaan deze blog.
Als je een (open-source) automatiseringsframework gebruikt, kan je dat het beste doen met een developers mindset. Dit betekent dat bepaalde developersprincipes gebruikt worden in het framework wat je bouwt voor je testautomatisering. Houdt daarom rekening met de principes van Object Oriented Programming (OOP). Maar niet alleen dát is belangrijk. Een goed automatiseringsframework kent volgens Aditi een 6-tal ‘Building Blocks’. In deze eerste van twee blogs over deze presentatie gaat het over de building blocks. Oftewel, waar moet je rekening mee houden als je een automatiseringsframework maakt.
Building Blocks
De building blocks voor een goed framework zijn eigenlijk letterlijk de fundering voor je framework. Het zijn de zaken die op orde moeten zijn in je framework. Deze building blocks zijn:
- Een wrapper om de web driver
- Testdata management
- Utilities
- Traceability
- Rapportage
- Browser management
Wrapper
Met een wrapper om de web driver kan je meerdere zelf geschreven regels code aftrappen als je de webdriver aanspreekt. Een voorbeeld: Stel je wilt een click-actie doen op een website. Je gebruikt daarvoor onder andere de methode findElement. Dit is een standaard functie die in de selenium library zit. Door een wrapper te gebruiken kan je vóór de findElement actie nog eigen code aftrappen. Dit doe je door gebruik te maken van de WebDriverListener. Deze gebruik je op het moment dat je je driver initialiseert en de WebDriverListener geeft je vervolgens de mogelijkheid andere methoden, zoals de beforeFindBy methode, te gebruiken. Zo maak je iedere keer, dat je een nieuw element op de pagina opzoekt, een screenshot.
// create an object of EventFiringWebDriver and pass the driver instance
EventFiringWebDriver eventDriver = new EventFiringWebDriver(driver);
// create an object of class WebDriverListener and pass the driver instance
WebDriverListener eventListener = new WebDriverListener(driver);
eventDriver.register(eventListener);
return eventDriver;Testdata management
Een van de belangrijkste, misschien wel hét belangrijkste building block is testdata management. Je hebt een voorziening nodig die bepaalt hoe je met je testdata om gaat. Je testdata uitlezen is een belangrijk onderdeel van je framework en je moet dan ook nadenken hoe je je testdata opslaat. Dit kan met xml, excel, json of wellicht een simpel tekstbestand. Testdata is een belangrijke pijler als je data-driven wilt testen. Als je dit goed inregelt, kan je al je testdata flexibel toevoegen en hoef je daarvoor in je daadwerkelijke code niets meer te veranderen. De kern hiervan is, dat je het flexibel opzet. Staat je testdata bijvoorbeeld in een excel bestand? Bedenk dan dat, wanneer je het uitleest, je ook te maken kan hebben met verschillende datumformats. Hier kan je op anticiperen in je code.
Utilities
Utilities zijn de “helpers”. De klassen die bestanden uitlezen, een connectie maken met een database, een API aanspreken of simpeler een eenvoudige test-String creëren in een bepaald format. Bestanden uitlezen kan betrekking hebben op je testdata management, maar moet in een breder perspectief worden geplaatst. Download jouw applicatie pdf’s? Hoe lees je die dan uit en verifieer je dat ze kloppen? Het hergebruiken van helpers bespaart je veel tijd, als je ze vaker inzet. Maak ze flexibel inzetbaar en zet ze ook op een aparte locatie in je framework neer. Zo kan je er makkelijk bij en is het zo overdraagbaar mogelijk.
Traceability
Ook traceability is een belangrijk onderdeel. Dit slaat voornamelijk op het gebruik van Tags. Cucumber heeft hier al een native voorziening voor, maar je kan ook zelf iets bouwen. Tags gebruik je om aan te geven bij welke story/feature iets hoort in Jira, op welke module binnen je app dit betrekking heeft, of het een positieve of negatieve test is, of dat het een smoke of sanity test is. Het grote voordeel voor jou is, dat je je testset significant kan verkorten. Je kan het uiteindelijk zelfs zo bouwen, dat in je CI/CD pipeline een hook staat, die een applicatie build op het moment dat nieuwe code wordt ingecheckt in GIT. Hierna kunnen automatisch op basis van meegegeven tags, precies die testen gestart worden, die betrekking hebben op de aangepaste code in GIT. Je automatisering rolt een rapport uit en jij weet de huidige stand van zaken, en dat na elke commit!
Rapportage & Browser management
De laatste twee punten spreken redelijk voor zich. Een goede rapportage functie is belangrijk. Zo kan je, nadat je testen klaar zijn, makkelijk vinden waar zaken fout zijn gegaan. Denk aan screenshots of video’s. Als je het bouwt zoals in de vorige paragraaf, kan je er direct mee naar de PO of naar je collega’s om te communiceren waar er nog een bug zit, die opgelost moet worden. Ook je browsermanagement is belangrijk. Maak een aparte klasse aan waarin je dit doet. Dan kan je in een properties-bestand aangeven welke browser je wilt gebruiken en kan je veel sneller naar een andere browser overschakelen. Selenium Grid bevat zelfs een functie waarmee je meerdere instanties van je testen tegelijk opstart, dan kan je meerdere browsers tegelijk testen. Maar je moet er natuurlijk wel voor zorgen dat jouw framework hier mee om kan gaan. Als je met browsermanagement begint, dan is het verstandig om eerst te kijken welke browsers je afnemer überhaupt gebruikt. Als dat maar één browser is, dan hoef je hier niet al te veel tijd aan te besteden, maar als je veel browsers moet ondersteunen, is dat een ander verhaal.
Hopelijk begrijp je de buildingblocks van een testautomatiseringsframework nu een beetje. Een wrapper, testdata management, utilities, traceability, een rapportage functie en browsermanagement zorgen voor een stabieler framework, maar het blijft natuurlijk een beetje vaag als dit de eerste keer is, dat je een framework gaat bouwen. De enige echte oplossing daarvoor is, het gewoon te doen! En mocht je er nog vragen over hebben dat sta ik of een van mijn collega’s klaar om je te helpen als je belt.
Benieuwd naar de gehele keynote: