In mijn meest recente opdracht moesten we aan de slag met het vernieuwen van iDEAL. Eén van de meest gebruikte en meest bekeken ketens van de bank. Kijkend naar de gebruikscijfers van Currence (Het bedrijf achter iDEAL, bron), die geven al jaren een stijgende trend aan. Als je hierin gaat sleutelen, is een van de belangrijkste vereisten dat het met de stabiliteit en snelheid goed zit. Vanuit De Nederlandsche Bank wordt van de aanbieders dan ook een beschikbaarheid van 99,8 % procent verwacht. En in die 0,2 procent zit naast onvermijdelijke storingen ook de tijd die je soms nodig hebt om systemen om te zetten of uit te breiden.
Een tool die je kan helpen bij het testen van de stabiliteit en snelheid van je applicaties, is Locust. Het is een open source tool die sinds 2010 in ontwikkeling is en steeds meer aan populariteit wint. Je kan het zonder kosten inzetten in je eigen omgeving, hoe groot of klein dat ook is. In deze blog zet ik uiteen wat je nodig hebt om er mee aan de slag te kunnen en wat mijn ervaringen met deze tool zijn.
Allereerst, wat is Locust precies? Het is een performance test framework, geschreven in python. Het simuleert een zwerm gebruikers (sprinkhanen), die vanuit het framework jouw service gaan belasten. Het is ook mogelijk om meerdere services aan te roepen in een vooraf bepaalde volgorde. Hiermee kan je goed een bepaalde gebruikersflow simuleren. Het aantal gebruikers geef je voorafgaand aan een test aan en deze wordt ook in een vooraf gesteld tempo opgebouwd. Vervolgens zal deze totale groep gebruikers steeds met een gerandomiseerd tijdsinterval terugkomen en zo je service blijven belasten. In onze service had je bijvoorbeeld eerst een gebruiker die een iDEAL betaling wilde gaan verrichten, daarna werd deze goedgekeurd door de klant en vervolgens wordt daar de status van opgehaald. Het is goed te beseffen, dat alleen de aanroepen naar de backend worden gesimuleerd. De pagina waar de klant dit normaal doet wordt niet gesimuleerd. Dat stuk is qua snelheid en stabiliteit ook erg afhankelijk van de configuratie van de gebruiker. Neemt niet weg, dat je dat wel moet testen, maar daar is Locust niet geschikt voor.
Locust is geschreven in Python en daarmee heb je gelijk ook een van de belangrijkste voor- en nadelen te pakken. Als je al een omgeving hebt waarin Python gebruikt wordt, is het erg makkelijk om het te integreren. Heb je geen Python kennis of mogelijkheden om het te draaien, dan wordt het wat moeilijker. Gelukkig is Python geen moeilijke taal, als je al kennis hebt van een andere programmeertaal kan je het jezelf snel eigen maken. Er zijn ook een heleboel cursussen beschikbaar. Ik ben zelf bijvoorbeeld in één dag ongeveer door deze cursus gegaan, dit geeft je een goede basis. Hier word je ook gelijk meegenomen in de installatie van Python en een IDE als je dat al niet had.
Als je een ontwikkelomgeving hebt met Python geïnstalleerd, kan je al vrij rap met Locust aan de slag. Het bevat een aantal standaard libraries die je op weg helpen, maar het is ook nadrukkelijk opgezet om er passend aan jouw omgeving zelf libraries voor te schrijven. De echte kracht van Locust komt naar voren als je binnen je bedrijf een kleine community start met daarin een aantal key ondersteuners. Dat was in mijn opdracht ook het geval. Een paar mensen onderhouden en ontwikkelen het generieke deel. Ze kunnen ook goed de code van de teams reviewen en verbeteringen die daar uitkomen kunnen ook weer doorgezet worden naar het generieke deel. Het was bij ons zelfs zo populair, dat teams ook hun functionele testen in Locust gingen doen. Dat kan, maar de vraag is of andere frameworks daar niet beter geschikt voor zijn.
Als je eenmaal een Locust project hebt draaien, zijn er verschillende manieren om de testen aan te zwengelen. Je kan vanaf de commandline parameters meegeven, dan wordt het project gebouwd en de testen uitgevoerd. Daarnaast is er ook functionaliteit om een GUI op te starten die je in de browser kan openen. Hierbij heb je wat invoervelden en kan je realtime zien wat je testen doen. Ook kan je achteraf mooie rapportjes uitdraaien waar het management heel blij van wordt. Als alles binnen de vooropgestelde specificaties blijft natuurlijk.
Uiteindelijk is ook Locust afhankelijk van de hardware waarop het draait. Zo merkten we, dat de limiet van de service die we testen niet bereikt werd, omdat onze laptops het niet aankonden om meer requests per seconden te versturen. Gelukkig zaten we toen al ver boven de maximale load die we wilden testen, maar het is wel goed daar rekening mee te houden.
Als je een ketentest wilt doen, is het ook van belang dat je testdata niet al te snel onbruikbaar wordt door de vele verzoeken die je verstuurt. Zo hadden wij een groep van 100 testgebruikers, maar schoten we daar zoveel iDEAL-betalingen mee in, dat de anti-fraude software al deze test accounts ging blokkeren. Je kan natuurlijk ook van mock data gebruik maken, maar dan is je test weer een mindere representatie van de echte wereld.
Het is ook mogelijk om je tests te in te plannen. Als je Locust integreert in een pipeline, is het mogelijk om het ook elke dag of week te laten draaien. Dit kan een mooi beeld geven van performance over tijd. Je ziet vaak bij teams dat bij een grote release wel performance testen aan het begin worden gedaan. Maar daarna laat men het liggen. Er worden allerlei features bijgebouwd, het wordt langzamer en niemand heeft het door. Door regelmatig performance testen in de pipeline te draaien voorkom je dat dit onopgemerkt kan gebeuren. Om dit te doen is wel wat extra kennis nodig van de bouwserver waar je Locust op wil draaien, bij ons was dat Jenkins, maar dat kan ook goed in vergelijkbare producten, bijvoorbeeld Azure Devops. Het wordt feitelijk een extra stap die je meeneemt in de bouw van je productie applicaties. Net als dat je andere geautomatiseerde testen zou toevoegen aan je pipeline. Deze blog gaf een kleine introductie in Locust. Het is een laagdrempelige tool die je heel flexibel kan inzetten en denk ik voor elke middel- tot grote organisatie van waarde kan zijn.