Tip & Tricks voor het efficiënt en effectief opzetten van data bij test automation
Door: Luc van Vugt!
Verslag door :
Test script, Wie maakt ze niet. Meestal worden de test gemaakt en getest. Als ze werken zonder fouten, dan pakken we het volgende punt op om te ontwikkelen. Simpel toch. Deze sessie ging niet over het maken van tests, maar of ze wel efficiënt zijn gemaakt. Eigenlijk had deze sessie net zo goed performance voor test automation kunnen heten. De sessie werd gegeven door Luc van Vught. Luc heeft geen uitleg nodig. Wie kent zijn boek “Automated Testing in Microsoft Dynamics 365 Business Central” niet. Tijdens deze sessie liet Luc zien wat bepaalde code voor de performance van je test doet en hoe je dit kan optimaliseren.
<foto Luc>
Hoelang duurt een test eigenlijk
Ik denk dat bijna niemand kijkt hoeveel seconden een test nodig heeft om uit te voeren. Vaak wordt de test gemaakt, uitgevoerd en als hij de status ‘Succes’ teruggeeft dan zit het vaak wel snor. Maar toch zit hier een uitdaging. Stel je hebt 10.000 tests die je moet uitvoeren en iedere test duur 2 seconden, dan duurt de test als gauw meer dan 5 uur. Deze doorlooptijd is niet haalbaar om dit bij ieder Pull Request uit te voeren. Hier moeten we dus een oplossing voor vinden. Of in ieder geval bekijken of we de tijd kunnen verkorten.
Wat kunnen we doen?
Wat kunnen we in de code veranderen om de code zo goed mogelijk te laten performen. Tijdens de sessie werden hiervoor twee punten behandeld. Wat moet ik eigenlijk testen en hoe zorg ik ervoor dat mijn data die ik nodig heb zo efficiënt mogelijk inricht.
Wat moet ik eigenlijk testen
Deze vraag is aan de ene kant makkelijk en aan de andere kant een uitdaging. Het spreek voor zich dat je de functionaliteit die je hebt gemaakt ook via de test automation moet testen. En hier komt ook gelijk de uitdaging. Vaak gebruikt je code onderdelen van Business Central om bepaalde acties uit te voeren. Ga je deze code meenemen in de test? en ben je dus indirect tests voor Business Central business logica code aan het schrijven.
Naast dat je ook BC business logica aan het testen bent, zorgt dit ervoor dat het uitvoeren van je test langer duurt. Probeer dit dus zoveel mogelijk te vermijden. Kijk of je bepaalde onderdelen los kan koppelen en deze in een losse test kan uitvoeren. Want waarom het werk van Microsoft nogmaals willen bouwen. Als we bovenstaand voorbeeld bekijken, wil je niet voor iedere test alle onderdelen doorlopen. Zorg ervoor dat je de drie blokken los kan aanroepen zodat je deze los kan testen.
Efficiënt data inrichten
Naast het loskoppelen van onderdelen in de code, zorgt het efficiënt inrichten van testdata er ook voor dat het uitvoeren van je code sneller gaat.
Voor alle test code uit via code, gebruik zo min mogelijk de user interface. Het gebruik hiervan zorgt alleen maar voor vertraging. Het spreekt voor zich dat het sneller is om via code een record aan te maken dan dat er een page moet worden geopend waarmee veld na veld met een waarde moet worden gevalideerd.
Ook het verwijderen van data in je test, om ervoor te zorgen dat je met een lege tabel begint, zorgt ook voor vertraging. Het kost tijd om de records te verwijderen, maar na de test wordt het ook weer teruggedraaid wat wederom tijd kost. Zorg er dus voor dat je test om kan gaan met de huidige data in de database.
Kijk waar je inrichtingsdata kan hergebruiken. Het kan zijn dat je voor iedere test ieder keer opnieuw een klant e/o leverancier aanmaakt. Kijk of je deze kan hergebruiken zodat deze niet opnieuw hoeven worden aangemaakt. Vaak worden er bij deze processen extra records aangemaakt die niet nodig zijn voor je test.
Probeer ook zo min mogelijk data aan te maken die niet nodig zijn voor je test. Ga geen landcodes aanmaken als deze niet nodig zijn.
Efficiënte Code
Ook in code kunnen we efficiënter werken. Doe geen validate als dit niet nodig is. Vaak worden er in de validate functies uitgevoerd die niets met jouw test te maken hebben. Hetzelfde geldt voor de insert/modify. Vraag je af of de code nodig is in deze triggers. Is het antwoord nee, dan kan je deze overslaan. Is het nodig om het record op te slaan in de database of kan ik deze vullen en doorgeven aan een functie. Als deze kleine dingen helpen mee om de doorlooptijd van een test te versnellen.
Conclusie
Het leuke aan deze sessie was dat het niet over het schrijven van tests ging. Het ging er in deze sessie om zodat je eens kritisch naar je tests kijkt en bedenkt, waar kan ik de code zo optimaliseren dat de test zo snel mogelijk wordt uitgevoerd. Hierbij nadenkend over waar kan ik een bypass doen en waar niet. Welke data heb ik nodig voor test en welke is overbodig.
Ik heb vandaag toevallig een test geschreven waar ik dit in de praktijk heb toegepast. In plaats van een functie aan te roepen die een veld op ja zet in verkoopkop, heb ik deze simpel op ja gezet via code. Normaal zou ik dit niet doen, maar de sessie van Luc heeft mij aan het denken gezet en ik dacht Fuck it, wat Luc kan, kan ik ook.