Robot Framework en Mockserver – een gouden combinatie

Auteur: John Kronenberg ● johnkronenberg@qacompany.nl

Redactie: Paul Beving

Waarom zou ik een Mockserver in de testautomatisering willen gebruiken?

In veel projecten, ook in die bij mijn opdrachtgever, worden componenten (lees: systemen, webservices, rest API’s) aan elkaar gekoppeld om een keten te vormen. Echter, in de tijd gezien zijn niet alle componenten waar mee gekoppeld moet worden op het juiste moment beschikbaar. Om de afhankelijkheid van het beschikbaar zijn van andere systemen weg te halen is het een goed gebruik om een mock framework in te zetten. Wij hebben, zoals aangegeven in mijn vorige artikel, voor Mockserver gekozen, omdat deze perfect integreert met Robot Framework.

Trouwens, om het subtiele verschil tussen een stub en een mock te respecteren, gebruik ik in dit artikel het woord mock in plaats van stub. Voor de verschillen tussen een mock en een stub verwijs ik graag naar dit artikel.

Het principe van mocking

In de wereld van mocking zijn er twee varianten die verschillende aanvliegroutes kennen, te weten een ‘domme’ mock en een ‘slimme’ mock. Het verschil zit hem in het feit dat een ‘domme’ mock, ongeacht welk bericht bij de mock binnenkomt altijd hetzelfde antwoord wordt teruggegeven en dat een ‘slimme’ mock op basis van een kenmerk van het binnenkomende bericht een specifiek response bericht terugstuurt. Bij een ‘slimme’ mock correleer je dus requests aan voorgedefinieerde responses en dat is exact wat wij nodig hebben.

De mockserver

In de basis is Mockserver een API. De documentatie van de API is in zogeheten Swagger formaat en hier te vinden. Je kunt de Mockserver gebruiken als een mock of als een proxy of een combinatie van beide. Wij gebruiken Mockserver alleen voor zijn mocking faciliteiten.

Om de belangrijkste termen van ‘onze’ Mockserverimplementatie te kunnen uitleggen is de volgende illustratie zinvol.

Een request is dus het binnenkomende bericht. Alleen als het binnenkomende bericht matcht (= correleert) met een expectation op basis van de gedefinieerde Request Matcher, wordt een in de expectation vastgelegde responsebericht teruggestuurd.

Onze implementatie

In dit voorbeeld hebben we een REST API die opvragenPersoon heet en zoals de naam al zegt persoonsgegevens teruggeeft.
Voor de API opvragenPersoon hebben we een folder met expectations in json formaat vastgelegd.
Iedere file (lees: testgeval) in de expectations folder heeft het onderstaande formaat. Als Request Matcher gebruiken we een XPATH. De json zegt zoiets als: ‘als er een request voor de opvragenPersoon API binnenkomt en in het persoonsnummer attribuut van het request xml staat de waarde 789, geef dan het opgegeven responsebericht xml terug‘.

{  
  "httpRequest": {  
    "path": "/opvragenPersoon",  
    "body": {  
    "type": "XPATH",  
    "xpath": "/Envelope/Body/persoon[persoonnummer=789]/persoonnummer"  
  }  
},  
"httpResponse": {  
  "body": "<HET TERUG TE STUREN XMLBERICHT>"  
  }  
}

Nu heb je dan wel de expectations voor de opvragenPersoon API in een folder staan, je zult deze expectations nog naar de mockserver moeten uploaden, om er in je testen gebruik van te kunnen maken. Daarvoor hebben we twee keywords in Robot Framework geschreven.

1. Starten van de Mock
2. Configureren van de Mock

Met de Robot Framework documentatie voor Mockserver library is het maken van dit script vrij gemakkelijk. Frank van der Kuur heeft de documentatie op zijn GitHub beschikbaar gesteld.

start de mock  
  [Tags] startMock
  Start Process java -jar "${STARTMOCKSERVER}/mockserver-netty-5.14.0-shaded.jar" -serverPort 1080  
  ${STATUS}= PUT http://${IP}:1080/mockserver/status  
  Log De mockserver is gestart? ${STATUS}

In ‘Configureren van de Mock’ keyword wordt met het library keyword ‘Create Mock Expectation With Data’ iedere file in de expectationsdirectory naar de server gebracht. Als je de code van het keyword ‘Configureren van de Mock’ wilt ontvangen, stuur mij dan even een mailtje.

Als finale stap hebben we twee Jenkins jobs neergezet. De eerste start de mockserver op en zorgt ervoor dat deze 24/7 in de lucht blijft. De tweede job zorgt ervoor dat van alle API’s de expectations naar de juiste locatie op de server wordt geüpload. Als nu de configuratie van de te bouwen service zo geconfigureerd is dat de mockserver wordt gecalled, dan kan de mockserver implementatie in de testen gebruikt worden.

Tip en conclusie

Het is nog best lastig om met Robot Framework een API implementatie te testen. Ik zorg er altijd voor dat ik de juiste endpoints die ik nodig heb in de Robot Framework keywords allereerst gedebugged heb met behulp van Postman.

Als dat wat je met een API wilt doen in Postman werkt, is de juiste call in Robot Framework implementeren een fluitje van een cent.

Ik kom tot de conclusie dat als jouw project gebruikmaakt van Robot Framework en je hebt een mock nodig, dan voldoet Mockserver prima. Ga ermee aan de slag en mocht je al spelend vragen krijgen, dan verneem ik die graag.