Veel teams worstelen met de overstap naar de nieuwe wereld, waar microservices, contract testing, en integratie-risico’s centraal staan. Langzamerhand begin ik er zelf achter te komen welke technieken hier van belang zijn om een succesvolle teststrategie op te zetten.
In een eerdere blog schreef ik al over componenten testen: een belangrijke testsoort waar ik een groot fan van ben. Maar als je alleen zwaar inzet op component testen, zorg je wel voor een hoge kwaliteit van je componenten, maar er blijft nog wel een groot integratie-risico over. Een risico dat met contract testen redelijk goed afgedekt kan worden.
Als je de term contract testen hoort, denk je al gauw aan de tool Pact. Mijn ervaring met Pact is tot nu toe dat het een erg complexe tool is die je forceert op een bepaalde manier te werken, waarbij iedere provider erg afhankelijk is van het kwaliteitsniveau van z’n consumers. Om nog maar te zwijgen over het feit dat deze manier van werken in strijd is met de agile waarde “individuals and interactions over processes and tools”.
Hierdoor ben ik verder gaan zoeken naar andere manieren om het integratie-risico af te dekken. Sinds de laatste paar jaar ben ik erg gecharmeerd van wat OpenApi (het vroegere Swagger) te bieden heeft in deze nieuwe wereld.
De Blind Dating App Case
Om de testaanpak concreet te houden wil ik als voorbeeld gebruik maken van een blinddating app, waar we met een klein team bij Praegus momenteel mee bezig zijn. Het (toekomstig) systeemlandschap ziet er als volgt uit:
We hebben een frontend met angular en ook een mobile app. Beide hebben dezelfde backend service zodat we logica zoals authenticatie op 1 plek kunnen beheren.
In het achterlandschap hebben we verschillende microservices met verschillende verantwoordelijkheden en verschillende afhankelijkheden zoals event hubs, databases, autorisatie en externe koppelingen. Een typisch landschap als je met microservices werkt.
Je kunt het zien als een volledig systeem, maar als je een teststrategie probeert op te zetten die voor meer snelheid en vertrouwen kan zorgen, is het belangrijk om in te zoomen op de losse componenten en op hun integraties die rood zijn gemarkeerd.
OpenApi
Met OpenApi kun je alle integraties die in de afbeelding in het rood zijn aangegeven vastleggen in een OpenApi specificatie bestand. Het liefst publiceer je dit bestand met een versienummer.
Vervolgens genereer je voor al je componenten de code voor deze integraties, op basis van dit OpenApi specificatie bestand. Dit kan je bijvoorbeeld doen met de vele OpenApi Generators. Zelf werk ik met name met de java/spring generators en de typescript/angular generator.
Door op deze manier al je integraties te genereren vanuit dezelfde OpenApi specificaties, minimaliseer je de integratie-risico’s. Je slaat in feite alle rode pijlen in bovenstaande afbeelding plat, waardoor hier een stuk minder fout kan gaan.
De overgebleven problemen die we in de praktijk hebben ondervonden komen met name door twee afzonderlijke oorzaken:
- breaking changes, maar ook daar zijn OpenApi tools voor te vinden, zoals de OpenApi diff.
- consumer service gaat te vroeg live. Hiervoor kun je voor een deployment, een check toevoegen of de juiste versie van de provider beschikbaar is op die omgeving, door bijvoorbeeld een /open-api-version endpoint toe te voegen aan al je services.
Conclusie: Begin met je specificaties om integratie en contract risico’s te minimaliseren
Door gebruik te maken van de OpenApi tooling begin je met het definiëren van je integraties, voordat je code gaat schrijven. Je bent hier ook niet afhankelijk van je consumers en je kunt dit proces inrichten op een manier die aansluit bij de werkwijze van de teams. Hierdoor is deze manier van werken beter in lijn met de Agile way of working.
Maar het belangrijkste in mijn ogen is nog altijd: op deze manier kun je integratie-risico’s afdekken op een manier die simpel is!
Nieuwsgierig geworden en wil je meer weten over testen? Neem dan contact op met Praegus – 085-1305977 / info@praegus.nl of kijk op www.praegus.nl
