Dit doet API-first voor je tests

In de afgelopen jaren maakt API-first een flinke opgang in de wereld van softwareontwikkeling. Hoe gebruik je die aanpak om de kwaliteit en efficiëntie van je QA-tests te verbeteren?

Wat is API-first?

Maar eerst even een paar stappen terug. API staat voor Application Programming Interface: een verzameling definities die een computerprogramma gebruikt om te communiceren met een ander programma of onderdeel. API-first is de naam van een redelijk recente trend in softwaredesign, waarbij de API als eerste wordt ontworpen en gemaakt. Hierbij richten de ontwerpers zich in eerste instantie op de behoeften van de gebruiker, in plaats van op wat nodig is voor de integratie van de applicatie. In de praktijk betekent dit dat interactie met data in je app in principe altijd mogelijk is via de API.

Wat is het voordeel van API-first voor softwareontwikkeling?

De belangrijkste winst die met deze aanpak kan worden gepakt, bestaat uit kostenreductie en een kortere time-to-market. Als je organisatie één dataset heeft die door vele applicaties moet worden gebruikt, is de API al gebruiksklaar voor elke applicatie, zodat er niets opnieuw gebouwd hoeft te worden. Maar daarmee zijn we er nog niet; het hele ontwikkelproces van API's kan worden geautomatiseerd (bijvoorbeeld met openAPI). API’s kunnen dus ook relatief snel worden gebouwd.

Hoe verloopt een traditionele UI-test?

Veel UI-tests worden ontworpen aan de hand van de zogenaamde black-box-benadering. Hierbij is de maker van de test niet bekend met de onderliggende software. Stel, je hebt een webapplicatie voor het bijhouden van je dagelijkse wandelingen met de hond. Er is een formulier om details in te vullen, zoals de duur van je wandeling, je route en aanvullende opmerkingen. Er is ook een functie waarmee je eerder ingevoerde informatie over een uitlaatronde kunt bewerken. Dan kan een test er als volgt uitzien:

Ook dit is een mogelijke test:

Dit zijn allebei valide tests die elk een echt scenario testen. Ze gaan echter beide uit van exact dezelfde voorgaande stappen, waarbij de wandeling met de hond eerst wordt ingevoerd. Dat gebeurt via de UI, wat even kan duren. De UI-tests wachten namelijk op de beschikbaarheid van andere elementen en kunnen bestaan uit meerdere testmomenten.

Geautomatiseerde UI-tests zijn ook niet altijd even stabiel. Problemen met WebDriver of netwerkproblemen zorgen soms voor lange laadtijden en storingen. Zelfs de meest ervaren automation tester kan niet altijd voorkomen dat externe afhankelijkheden problemen veroorzaken bij de test. Bovendien zijn UI-tests meestal duur, omdat ze meer tijd en middelen vergen dan een API-test.

Hoe kan dat beter met API-first?

Bij API-first vormt de API – hoe kan het ook anders – een belangrijke eerste stap. Al bij de ontwikkeling van de API’s worden functionele tests uitgevoerd. Het is ook goed mogelijk dat er al wat userflow-tests worden gedaan, om te controleren dat de in- en output van de API's goed samenwerken. Teruggrijpend op het concept voor onze app voor uitlaatrondes, zou je een gebruiker kunnen oproepen door een API. Met de gebruikers-ID van deze API, kun je vervolgens een entry met een uitlaatronde voor die gebruiker aanmaken.

Als je tools gebruikt die compatibel zijn met je tools voor de UI-tests, kun je nu ook testmethodes gebruiken die al gecreëerd zijn voor die API's. De teststap waarbij de entry van de uitlaatronde wordt aangemaakt, oogt nog altijd hetzelfde. Maar in plaatse van een serie testmomenten in de UI, wordt er contact gemaakt met de API. Die API is al getest dus je weet dat het goed zit. API-tests zijn vaak ook stabieler. Je loopt dus minder kans op storing wanneer je test op afhankelijkheden. Deze API's kun je vervolgens gebruiken bij het bouwen en afbreken van al je tests, waarmee een hoop tijd wordt bespaard.

Misschien vraag je je nu af of we de app nog wel echt zó testen, zoals de gebruiker ermee werkt. Gaat het hier werkelijk over de user experience? Bedenk je daarbij dat het hierboven gegeven voorbeeld slechts een subset van tests in een testsuite is. En die testsuite is nog altijd ontworpen om elk deel van de app te controleren. De suite van het bovenstaande voorbeeld behoort ook een test te bevatten die de stappen voor het invoeren van de uitlaatronde via de UI controleert en kijkt of het allemaal werkt zoals verwacht. Een belangrijk verschil is dat de stappen die normaal gesproken binnen een testsuite meermaals zouden worden uitgevoerd, hier tot het minimum worden beperkt. De manier waarop we de testgegevens organiseren is gelijk aan hoe de applicatie data gebruikt, omdat het allemaal gebruikmaakt van API's.

De bovenstaande UI-stappen kunnen dan vervangen worden door één API-oproep:

Kortom

Onze teams voor softwareontwikkeling hanteren een principe voor softwareontwerp dat kosten bespaart en zorgt voor een kortere go-to-market-periode. We kunnen dit ook gebruiken voor onze tests, zodat we sneller en efficiënter kunnen testen. Daarmee kunnen we dus ook vaker testen, wat leidt tot betere kwaliteit van de applicaties.