Testen binnen CI/CD met MUnit in MuleSoft

Deze blog is geschreven door SynTouch, een dochteronderneming van SUPERP.

In moderne softwareontwikkeling is Continuous Integration en Continuous Deployment (CI/CD) de standaard geworden voor het snel en betrouwbaar leveren van nieuwe functionaliteiten. Binnen dit geautomatiseerde proces is testen niet langer een optionele stap, maar een essentieel onderdeel van elke succesvolle release. Voor MuleSoft-ontwikkelaars betekent dit dat het testen van API’s en integratieflows vanaf het begin moet worden ingebouwd en dat is precies waar MUnit een cruciale rol speelt.

Unit vs Integratie testen

Unit testen richten zich op het testen van individuele onderdelen van een applicatie —zoals een specifieke Mule flow of component— los van andere systemen of afhankelijkheden. Ze zijn snel, geïsoleerd en ideaal voor het valideren van logica. Integratietesten daarentegen simuleren hoe verschillende onderdelen samenwerken, inclusief interacties met externe systemen, databases of API’s. Met MUnit kom je dichtbij integratie testen door het gebruik van mocking, spies en assertions om gedrag te controleren.

Maar het hebben van integratie testen om de hele API-led keten te testen is zeker nog nodig.

Voor integratie testen heb je een omgeving nodig waar alle applicaties draaien voor een test van Experience tot en met System applicatie. Als je omgeving het toelaat wil je dit nog verder uitbreiden tot een End-to-End (E2E) test waar je de hele flow test vanuit de start applicatie of tot de eind applicatie.

niet om data lineage heen.

Deep dive

Nu gaan we specifiek verder op Munit om vroegtijdig te kunnen testen. We gaan er hiervan uit dat je al wat ervaring hebt met Munit door bijvoorbeeld het doen van Mulesoft Certified Developer 1 certificering. Mulesoft laat graag de MUnit test recorder zien als voorbeeld van makkelijk test maken, maar het heeft wat voeten in de aarde om een hele omgeving op te tuigen om tegen aan te testen. Een sneller voorbeeld van het aan de slag kunnen met testen is de functie om je RAML te gebruiken om een kale Munit te krijgen die je RAML contract gaat testen.

Hoe uitgebreider je de RAML maakt met voorbeelden hoe meer die je kan helpen met een Munit test maken, hier een voorbeeld Munit test, die de status code en payload controleerd.

HTTP status code 500 is hier het verwachte antwoord samen met een voorbeeld bericht. De payload bestanden kopieert die uit de RAML in de ‘scaffold’ en wordt gerefereerd met de ‘MunitTools::getResourceAsString’ functie. De ‘scaffold’ krijg je door op de apikit router connector met rechter muisklik deze Munit suite te laten maken. Deze haalt zoals de naam zegt de inhoud van het bestand op als string zonder het een type te maken en gaat een vergelijking maken met de uitkomst van de execution. Hiervoor wordt de ‘write’ functie gebruikt hier zitten echter risico’s aan omdat je opnieuw een transformatie doet van de uitkomst. Hier moet je goed opletten op de configuratie-eigenschappen voor inhoudstypes zoals csv en xml.

General tips

Bij het gebruik van een ‘Spy’ kan je gedurende de executie van de test waardes controleren. De valkuil is alleen dat je test ook slaagt als die deze ‘Spy’ overslaat. Daarom is het verstandig om altijd een ‘Verify call’ te doen die naar hetzelfde refereert als de ‘Spy’.

Voor het gebruik van de Validation deel van een Munit test moet je opletten als je error scenario’s test. Bij het gebruik van de Expected error type wordt de Validation stap volledig overgeslagen en kan je dus niks meer valideren. Wat een vervanging is voor deze expected error type is een ‘Try’ met een ‘On error continue’. Je moet dan nog wel controleren of ook echt de error langs komt. Door bijvoorbeeld een ‘assert that’ van een payload of een ‘verify call’ op een connector in de error handler.

In de Execution wordt vaak een ‘Set Event’ gebruikt bijvoorbeeld als je de code laat generen door de recorder of vanuit de RAML. Het nadeel van dat component is dat je de waardes in 1 regel in het UI menu moet neerzetten en je payloads als string moet inladen of dataweaves moet importeren. Het geeft wel goed het overzicht van payload, atrributes, errors en variablen maar is minder leesbaar voor debuggen. Een alternatief is een simpele ‘transform message’ als je daarin nog steeds naar een bestand refereert voor de source code kan je die ook hergebruiken in verschillende testen.

Munits wil je het liefst opbouwen met gegevensbestanden maar afhankelijk van de inhoud is er bijvoorbeeld een referentie naar een datum of dynamisch eigenschap die dat weerhoudt. Dan is het gebruiken van een Dataweave script nodig om deze voor de payload vergelijking te vervangen. Functies hiervan zijn vaak handig om te hebben in gedeelde bronnen.

Als je in meerdere testen dezelfde ‘mock when’ nodig hebt dan is het handig om deze in een aparte flow te zetten en met een ‘flow ref’ te gebruiken in de Behavior. Meerdere ‘mock when’ componenten kunnen zo ook in een aparte flow als een bepaalde flow veel vertakkingen heeft. Dit versimpelt het overzicht in de Munit test aangezien de rigide vormgeving binnen Anypoint Studio.

Met parameterization kan je gehele Munit testen hergebruiken en met alleen een yaml input verschillende testen aftrappen. Zie in de link een voorbeeld hoe je dit kan opzetten.

Je hebt ook een ‘Before suite scope’ en een ‘Before test scope’ en een ‘after’ variant waarmee je voor of na alle test of elke test voorbereidingen of opschoning kan draaien. Dit kan zoiets zijn als altijd dezelfde payload meegeven of een objecstore klaarzetten of opruimen. Zo kan je bijvoorbeeld een input gebruiken voor all testen in een ‘MUnit Test Suite file’ met in elke test apart de aanpassing specifiek voor elke test. Zo hoef je minder wijzigingen bij te houden in aparte bestanden.

Je kan in Anypoint studio een Munit aftrappen en in de UI kan je met ‘test resources’ aangeven welke gehele bestanden die die moet aftrappen. Met ‘test’ kan je specifiek een of een paar tests aftrappen zodat je daar snel resultaat hebt. In de command line kan je dit ook doen met ‘mvn clean test -Dmunit.test=test-suite.xml#YOUR_TEST_NAME_HERE’

Ten laatste heeft Mulesoft ook een cookbook gemaakt voor Munits dat ook al veel voorbeelden geeft en een uitbreiding is van de bestaande intro die je krijgt tijdens een cursus van Mulesoft zelf.

Workshop

Hierin gaan we een test opzetten op basis van een RAML die je maakt. Een RAML is vaak het begin punt van een API bouwen en daarop heeft Mulesoft dus ook de meeste functionaliteit gebouwd.

Om het zelf te proberen heb je een raml nodig hiervoor downloaden we die van Mulesoft. Je kan het voorbeeld via deze link bekijken.

Daar krijgen de file api-designer-experience-api-1.1.5-raml.zip. Deze plaatsen we uitgepakt in een nieuwe mule project.

Hier kunnen we met een linker muisklik op de api.raml de ‘Generate Flows from Local Rest Api’ starten, deze maakt het bestand ‘api.xml’ aan met de apikit router geconfigueerd en alle flows met de HTTP-requests.

Hier kan je met een linker muisklik op de ‘APIkit Router’ de Munit test suite aanmaken door ‘Create Test Suite for api.xml from API Specification’ aan te klikken. Deze maakt het bestand apiapikit-test.xml aan in de folder src/test/munit en onder src/test/resources zijn 2 folders aangemaakt scaffolder/request en scaffolder/response voor alle bestanden die nodig zijn.

Je kan met de Munit die je hiermee creëert aan de slag met Test-driven development aangezien je met een volledige RAML-specificatie al je eerste validatie hebt.