Wat komt er kijken bij API testing. Onlangs woonde ik een testnet themavond bij waarin Lianne Klaver van Polteq een presentatie gaf over API testen middels Postman en Vincent Vonk van CGI middels SoapUI.
Dit samen zorgde voor een mooi stuk kennis over deze twee tools en de verschillende interfaces, maar ook over het testen van API’s in het algemeen.

Deze themavond, in combinatie met mijn reeds aanwezige kennis over API testing, gaf me inspiratie  en leidde tot dit korte & bondige verslag. Lianne gaf aan dat de kortste cursus die zij gaf over dit onderwerp een hele dag was. Het in een presentatie van één uur doen, was dus een hele uitdaging.

Het is een high-over blik op API testing, want inderdaad heb je zo een heel boekwerk vol.

1: API testen vs GUI testen

Veel applicaties hebben een frontend (GUI) en worden via die frontend getest met bijvoorbeeld selenium. Echter, heel veel backends met webservices (API’s) zijn afzonderlijk te testen.
De complexiteit bij het testen via de frontend zit hem o.a. in de timing. Wordt de waarde die ik wil verifiëren, al getoond. Tevens bestaat de kans dat testautomatisering faalt op schermen, omdat er bijvoorbeeld een errormelding is over een knop, maar op het scherm die knop niet in te drukken is.

Dergelijke issues heb je niet bij API testen. Via de API verstuur je een request, wacht op de response en valideert deze. Kortom, minder false-negatives.

Volgens de veelgebruikte testpiramide is het ook verstandig alles wat je op de API kunt testen te doen en niet via de GUI.

2: De interfaces:

Er zijn diverse interfaces en twee veelgebruikte wil ik uitlichten:

Een SOAP (Simple Object Access Protocol) interface wordt beschreven middels een WSDL (je spreekt uit: wisdel). Hierin staat hoe de structuur van het request en de response moet zijn. Ook wel eens gezien als de interfacebeschrijving.
Bij voorkeur is de oplevering van deze WSDL zeer vroeg bij de ontwikkeling zodat de tester zijn testen op basis hiervan reeds kan implementeren danwel het vragende systeem reeds hun deel van de interface kan implementeren.
Een nadeel hiervan is dat, als de interface toch wat anders wordt, de WSDL aangepast moet worden en daarmee mogelijk de testen ook al, indien het request een andere structuur krijgt.
Het request dat je naar een SOAP interface stuurt, is een XML evenals het antwoord. Daardoor wordt SOAP als beperkter gezien dan REST, welke ook een JSON kan terugsturen.

Bij de REST interface is het een HTTP request. De bekendste opties zijn Get, Put, Post en Delete. De 4 onderdelen van CRUD (Create Read Update Delete). Die bepalen het type vraag/opdracht dat je naar de interface stuurt. De specificaties van het request worden als parameters meegegeven. Bijv: www.google.nl/api/search/?search=testnet

3: De tools:

API testen zijn met diverse tools uit te voeren, twee veelgebruikte zijn Postman en SoapUI.

3.1: Overall

Voor beide tools geldt dat het gebruik doorgaans in 4 stappen gaat:

• Stap 1 is het handmatig uitvoeren van API testen
• Stap 2 is het opslaan en hergebruiken van testen middels de runner
• Stap 3 is middels variabelen de testen beter herbruikbaar te maken (voor meerdere omgevingen)
• Stap 4 is om deze testen vanuit je delivery pipeline (Bijv. Jenkins of Octopus deploy) aan te roepen.

Zowel Postman als SoapUI staan het gebruik van environment variabelen toe. Indien je specificeert dat de testen uitgevoerd worden op de URL “SUT/api (SUT = System Under Test),
neem je drie sets variabelen op:

TEST: SUT = test.newspark.nl
ACPT: SUT = acpt.newspark.nl
Prod: SUT = www.newspark.nl

Op deze manier kun je dezelfde testen uitvoeren in verschillende omgevingen zonder dat je overal de URL’s moet aanpassen.

Zowel Postman als SoapUI zijn als Mock (stub) te configureren. Op deze manier is het mogelijk bijv. een frontend reeds te testen met een, door Postman/SoapUI gesimuleerde backend, nog voor de backend klaar is.

3.2: Postman
Postman is een chrome app die je dus vanuit chrome kunt installeren en starten.

Voor het uitvoeren van validaties op bijv. de body zijn diverse mogelijkheden. Postman levert code snippets, oftewel een voorbeeldcode van de juiste structuur, waarin je zelf nog aanpassingen kunt doen om zo tot de juiste test te komen. Te denken valt aan:

– tests[“Status code is 200”] = responseCode.code === 200;
– tests[“Content-Type is present”] = postman.getResponseHeader(“JSON”);
– tests[“Response time is less than 200ms”] = responseTime < 200;

Deze code is geschreven in javascript. Zo zie je maar dat een tester van tegenwoordig ook eigenlijk wel moet kunnen programmeren.

Wil je de opgeslagen testen van Postman in je delivery pipeline hergebruiken, dan doe je dat met Newman. Dit is de CLI (Command Line Interface) variant van Postman. Newman zorgt voor de vertaling van je opgeslagen testen naar de pipeline, je hoeft de testen dus niet opnieuw te schrijven.

3.3: SoapUI
In tegenstelling tot wat de naam doet vermoeden, is SoapUI niet alleen in staat SOAP interfaces te testen, maar ook REST interfaces testen net als Postman.

SoapUI is te gebruiken als gratis versie, dan wel als uitgebreidere betaalde versie.

In de basis werkt SoapUI vergelijkbaar aan Postman. Ook bij SoapUI komen veel mensen niet veel verder dan stap 2, het opslaan en hergebruiken van gedefinieerde testen. In sommige gevallen zelfs tot alleen het versturen van een opgeslagen XML bericht en het handmatig verifiëren van de response.

4: Wat voor dingen kun je testen van een API

4.1: HTTP response code
Bij elke response van een API krijg je ook een HTTP response code. De bekendste zijn 200 (OK), 404 (incorrect verzoek, bijv. de ID waarvoor je iets opvraagt is onbekend) en 500 (algemene server error). Deze codes zijn ook te verifiëren. Indien je bijv. een sunny-day-scenario hebt, verwacht je een 200 responsecode met een bepaalde content in de body. Krijg je een 404 of een 500 code terug, weet je al dat er iets mis is. De testen op de body zijn dan niet direct nuttig.
Een uitgebreide lijst van alle codes is te vinden op: https://nl.wikipedia.org/wiki/Lijst_van_HTTP-statuscodes
De grappigste is 418, ingevoerd als 1 april grap. Een online thee-machine geeft daarmee aan het verzoek voor koffie niet te kunnen uitvoeren.

4.2: Body
De body bevat bijvoorbeeld de gegevens van de klant met de ID uit het request. In dit geval is te testen of inderdaad alle verwachtte gegevens van de klant worden teruggestuurd.

4.3: Header
De header wordt vaak vergeten, maar ook die kan belangrijke informatie bevatten. Te denken valt aan het type content (bijv. html of JSON).

4.4: Responsetijd
Elk response komt binnen een bepaalde tijd terug. Aan deze responsetijd zitten vaak performance eisen. Te denken valt aan: 99% van de calls moet binnen 1 seconde antwoorden opleveren, dan wel gemiddeld moet binnen 500 milliseconden een antwoord komen. Voor elke call is deze responsetijd te valideren. Daarbij is het doorgaans nodig veel call’s uit te voeren en te zien of inderdaad 99% binnen de 1 seconden blijft, dan wel gemiddeld binnen 500 milliseconden een antwoord komt. Als een antwoord pas na 3 seconden komt, is dat doorgaans geen falende test. De interface is alleen erg traag, dus kun je achterhalen hoe dit komt.

5: Wat wel en wat beter niet te testen bij API testen:

Bij het testen op responsetijd, kan dit snel leiden tot fails waarbij je je goed moet afvragen of het wel echt een fail is. Als 99% van de call’s binnen 1 seconde beantwoord moet worden, is het dus niet een fail als <1% er 2 seconden over doet.

Zijn er harde requirements, bijv. antwoorden binnen 5 seconden, dan kun je hierop testen en de testen laten falen als dit meer tijd kost. Anders is het vooral interessant voor het performancetesten om trends waar te nemen.

Middels de test: “tests[“Body matches string”] = responseBody.has(“string_you_want_to_search”);” is te achterhalen of een bepaalde tekst voorkomt in de body. Echter, waar en hoe vaak die tekst voorkomt, checkt die niet. Is de gezochte tekst niet specifiek genoeg, bestaat de kans op een false positieve. Ook als je een specifiek zoekt, bijv. komt bepaalde tekst op regel 9 voor, krijg je snel een false negative, want komt in de response een extra keyword voor, kan het antwoord naar regel 10 verspringen. Hiermee moet je dus slim omgaan en zoeken naar een balans tussen niet te specifiek, maar ook niet te ruim.

6: Welke tool is de beste?

Zoals met zoveel soorten tools, is het een kwestie van smaak/gewenning en is 1 tool niet altijd beter. Zijn bij een klant al veel testen met Postman geschreven, is het doorgaans niet handig alles om te zetten naar SoapUI. Zoek vooral zelf uit welke tool voor jou fijn werkt en aan kan wat nodig is. Kan dit alleen met een betaalde versie, dan kan het nuttig zijn te onderzoeken of een andere tool wel jouw wensen vervult met de gratis versie.