Ketentesten is zó 2010!

Ketentesten falen in een IT-wereld met Cloud en Microservices. Lees mijn ervaringen met geautomatiseerd contracttesten.

Ketentesten = Testing from hell

Ik herinner het me nog uit mijn beginjaren: vier weekenden per jaar deden honderden (!) mensen uitgebreidde keten- en regressietesten bij nieuwe releases van (SAP)applicaties. Dat kostte heel, heeeuuul veel geld. En ook nu zie ik handmatige ketentesten nog plaats vinden, bijvoorbeeld bij bedrijfsoverstijgende “sector”-releases.

Veel bedrijven hebben ondertussen ontdekt dat dit echter niet meer werkt in een wereld van Microservices, Cloud en SaaS-applicaties. Waar meerdere keren per dag nieuwe versies gereleased worden naar productie. Ga je dan elke keer (handmatig) ketentesten? En is er nog wel sprake van een “keten” in een web van onderling afhankelijke microservices?

Kortom het oude principe van ketentesten (“End-to-end”) testen is geworden tot een hel.

Ketentesten is zó 2010… ga contracttesten!

De oplossing die grote bedrijven zoals Netflix, Uber Amazon, etc gebruiken is Contract Testing. Dat is het geautomatiseerd testen van de koppelingen waarmee microservices en applicaties met elkaar praten. Je test wat een microservice (of SaaS applicatie) voor dienst aanbiedt op zijn koppeling (op zijn API) en wat de aanroeper daarvan gebruikt. Je test kortom het contract tussen de aanroeper en de microservice. In dat contract staat welke gegevens de aanroeper de API van de microservice in stuurt en wat voor data de aanroeper dan terug wil hebben:

Als je dan een nieuwe versie wil releasen van je microservice, dan test je deze in je CI/CD straat geautomatiseerd tegen dit contract. Als alle contracttesten “groen” zijn, dan weet je dat alle aanroepers van jouw microservice blijven werken! “Releasing with confidence” heet dat ook wel.

Contracttesten bij Alliander

Bij het bedrijf waar ik werk testen sinds kort enkele teams met contracttesten. Daarbij wordt Pactflow gebruikt om de contracten in op te slaan. Daarnaast gebruiken we Sonar voor code kwaliteit.

Ervaringen en aandachtspunten

Contracttesten (of eigenlijk Consumer Driven Contracts ) blijkt zoals veel oplossingen in de IT niet de heilige graal te zijn. Je kan er bijvoorbeeld geen publieke API’s of API’s van SaaS applicaties mee af testen. Want Twitter of SAP gaan geen contract opstellen voor de aanroep die jij doet naar hun API’s …

Voor microservices die je aanbiedt op een API-Management wringt het ook nog een beetje. Je wilt eigenlijk voor elke aanroeper van je API een contract maken, zodat je 100% geautomatiseerd zeker bent dat je nieuwe versies van je microservice kunt releasen. Maar bij API-Management weet je niet wie je aanroepers zijn (of is er iemand die hier een oplossing voor heeft?).

Tenslotte kun je niet altijd helemaal zonder functionele eindtesten: je wilt bij grote wijzigingen misschien toch wel meer zekerheid dat je gebruikers de functionaliteit krijgen die ze verwachten. Deze extra handmatige testen kunnen echter heel beperkt zijn, als je daarnaast goede geautomatiseerde testen hebt voor je Frontends (bijvoorbeeld met protractor van Angular) én functionele monitoring inricht op productie met tools die de klantreis simuleren (zoals Uptrends ). Overigens: functionele klantreismonitoring is natuurlijk ook handig om problemen te ontdekken voordat je gebruikers gaan klagen :-).

Meer informatie 

• How Pact(Flow) works 
• Contract Testing met Factflow 1-2-3  door Alliander java ontwikkelaar Robbert van der Zon
• Martin Fowler over Consumer Contracts 

Wat voor (keten)testen doe jij op dit moment? En als je contracttesting gebruikt: hoe ga je om met API-management?