Flaky testen en dieprode, door ieder genegeerde, dashboards. Onleesbare testen, omdat men zegt BDD te doen, maar de scenario’s zien er uit als old-skool testscripts. En angst voor het toevoegen of onderhouden van geautomatiseerde testen. Dat zijn allemaal problemen die niet hoeven te bestaan, als je het testautomatisering framework de juiste structuur geeft.
Testautomatisering is software. Software die architectuur nodig heeft. Software die ook moet voldoen aan kwaliteitseisen. Dat houdt in dat het goed gestructureerd moet zijn. Dat de code en testen leesbaar en onderhoudbaar zijn. Dat voor iedereen in het team het duidelijk is wat waar getest wordt, ook voor nieuwe leden. Testautomation done right, kan zelfs dienen als leerschool voor nieuwe leden, om er achter te komen welke functionaliteiten in de applicatie aanwezig zijn.
Nee, ik verkoop geen luchtballonnen of luchtkastelen, in plaats daarvan probeer ik hieronder een opzet van je testautomatisering framework te geven die je kan helpen.
Testautomatisering bestaat er om het team te helpen in control te zijn en het verkorten van de feedbackloop. Om de automatisering voor het team te laten werken, moet men weten wat er getest wordt, moeten de testen stabiel zijn en doen wat ze zeggen dat ze doen, en tot slot moet men snel nieuwe testen kunnen maken. Een goede opzet vergt aan het begin van het project de meeste tijd, met als doel een versnelling later in het project.
In onderstaande ga ik met name in op een Cucumber / SpecFlow / Reqnroll achtige testautomatisering met Behaviour Driven Development scenario testen. Echter, deze structuur is bruikbaar voor elk testautomatisering project.
Testautomation done right
Een goed testautomatisering framework bevat code op meerdere lagen. Elke laag heeft haar functie en de lagen zouden idealiter niet in elkaar over moeten lopen. In elke laag bestaat code die herbruikbaar is over meerdere testen heen.
- Functionele business gerichte testbeschrijvingen (fixtures/features & scenario’s)
- Koppeling tussen de testbeschrijvingen en de business-logische code (stepdefinitions)
- Business logische code (step implementation, preparators, business objects, page objects)
- Koppeling tussen de business logica en technische logica
- Technische logische code (communicatie met applicatie/database)
Functionele / business gerichte testbeschrijvingen
Hiermee worden de features en de scenario’s bedoeld. De belangrijkste functie hiervan is dat ze leesbaar zijn, zodat er snel overzicht gekregen kan worden wat waar getest wordt. Het snel kunnen bepalen van de gewenste compleetheid.
De features moeten daarom echt gebruikt worden waarvoor ze oorspronkelijk bedoeld waren en dat is het omschrijven van één functionaliteit. De feature-bestanden kunnen dan ook in een logische mappenstructuur leven.
De scenario’s dienen kort opgeschreven te worden in ‘Gegeven’ (voor situatie), ‘Als’ (actie) en ‘Dan’ (controle) met korte en duidelijke scenario omschrijving. Heel soms is er een ‘En’ stap nodig, maar dat moet een uitzondering zijn. Slim gebruik van variabel gemaakte stepdefinitions helpen vervolgens met het snel kunnen toevoegen van nieuwe testen.
In Behaviour Driven Development (BDD) beschrijf je het gedrag van de gebruiker, niet de implementatie die het team heeft gebouwd. Je beschrijft WAT de gebruiker doet, niet HOE deze dat doet. Dus de gebruiker wil bijvoorbeeld een document aanmaken en wil niet ‘naar een url navigeren’ of ‘op knop X drukken’.
Koppeling tussen de testbeschrijvingen en de business-logische code
Dit niveau bevat de stepdefinitions met leesbare herbruikbare verwijzingen naar diepere code. Meer hoeft er niet geprogrammeerd te worden op deze laag. Het bevat puur de stappen die uitgevoerd moeten worden om een gegeven, als of dan uit te voeren. Met leesbare code van uitgevoerde stappen, zonder uitvoerende code.
Je kan bijvoorbeeld in de stap een gebruikerstype als ‘auteur’ en een schermnaam als ‘overzicht’ meegeven en in deze laag roep je een ‘OpenApplicatieMetGebuikerstype(gebruikerstype)’ en ‘NavigeerNaarScherm(schermnaam)’ aan. Een ander voorbeeld is een controle stap waar je controleert of een document ‘gelezen’, ‘bewerkt’ of ‘verwijderd’ kan worden, met een diepere verwijzing naar ‘ControleerRechtenOpDocument(rechtenNiveau)’.
Business logische code
De business logische code laag is ervoor om de acties uit te voeren om de testen uit te voeren. Dit bevat bijvoorbeeld het ‘navigeren naar een pagina’, het klaarmaken van benodigde testdata, het bewaren van de testdata in business objecten (document met naam, type, etc of persoon met naam, geslacht, bsn, etc) en het vertalen van de string variabelen naar business logische variabelen (objecten, enum).
Functies zijn gericht op Testdata en Testuitvoer. Voorbeelden hiervan zijn:
- het (gerandomiseerd) genereren en aanmaken van testdata volgens functionele regels
- objecten van functionele actoren (persoon, document, gebruiker)
- het navigeren naar elk mogelijk scherm volgens functionele regels
- kiezen en inloggen van gebruikers
- enums van bijv. schermnamen, gebruikers, documenttypes en statusnamen
Koppeling tussen de business logica en technische logica
In deze laag vind je alle code die nodig is om te interacteren met bepaalde onderdelen en utilities zoals een random data generator.
Hier vind je code die nodig is om bepaalde pagina-objecten te kunnen bedienen, zoals het invullen van invulvelden, interacties uitvoeren met knoppen of het ophalen van meldingen, waarschuwingen of errors.
Daarnaast vind je de ‘data generatoren’ in deze laag, bijvoorbeeld van gerandomiseerde data, met een ‘random string van een bepaalde lengte’, random boolean of getallen, maar ook voor het genereren van een geldig bsn of geldige bankrekening.
Technisch logische code
De laatste laag bevat puur de code die nodig is om de applicatie te benaderen. Bijvoorbeeld om de browser instantie op te starten, aanroepbaar te maken voor de testen en weer op te ruimen. De connectie met de database maken, zodat op andere niveaus queries uitgevoerd kunnen worden. En om de aanroep van API’s af te handelen.
Tot slot
De structuur uitgelegd in deze blog is voor mij zo verschrikkelijk logisch, maar ik blijf projecten tegenkomen met bdd-testscripts en niet-te-onderhouden en niet-te-lezen code. Dit heeft ertoe geleid dat ik mij geroepen voelde om voor het eerst in mijn leven een Blog te schrijven, mooi om af te vinken net voor m’n 40ste.
Dit blog staat zeker niet op zichzelf, binnen Praegus is hier al veel over geschreven en gesproken. Met name de blogs van Fin zijn erg interessant om te lezen, deze geven meer context of juist een stap-voor-stap benadering om met een framework te starten.
Nieuwsgierig geworden en wil je meer weten over testen? Neem dan contact op met Praegus – 085-1305977 / info@praegus.nl of kijk op www.praegus.nl