Contract-based testing: zo stel je het eerste contract op

Wat is Contract-based testing? “Bij Contract-based testing voer je testen uit volgens de afspraken die vastgelegd zijn in een contract tussen de consuming applicatie en de providing applicatie”, legt Peter Geurtsen uit. “Zo zorgt Contract-based testing voor extra zekerheid. Hierdoor heb je meer garantie dat jouw applicatietesten voldoen aan de specificaties van de interface.”

Waarom Contract-based testing?

Onze applicatieomgeving verschuift steeds meer van een monolithische naar een microservice architectuur, met services die agile ontwikkeld worden. Daardoor kan de overkoepelende integration test pas uitgevoerd worden als alle microservices uitontwikkeld zijn. Met Contract-based testing maak je een shift left: je voert de integratietesten eerder in het development-traject uit. Zo zorg je dat er in een later stadium minder getest hoeft te worden en dus ook minder fouten optreden. Een ander voordeel van Contract-based testing is dat deze methode de consumer en provider stimuleert om te overleggen. “Faalt een test, en voldoet deze dus niet aan de voorwaarden vastgelegd in het contract, dan dwingt het contract de consumer en provider om problemen samen op te lossen”, zegt Peter Geurtsen. “Pas als beide partijen deze samen opgelost hebben, kunnen ze de software implementeren op hun master in de pipeline. Als laatste biedt Contract-based testing autonomie aan een applicatie om een versie direct te deployen indien het voldoet aan het contract. Daardoor ben je niet meer afhankelijk van een interfacend systeem om integratie of end-to-end testen uit te voeren.”

Hoe creëer het eerste contract? 

“Je start met een unit-test van de consumer applicatie. De resultaten daarvan vormen de input voor het eerste contract. Dit zijn de specificaties die de provider nodig heeft voor het ontwikkelen van de interface. Daarnaast gebruikt de provider deze informatie om de data en specificaties in zijn stubs te creëren. Door deze aanpak beschikken zowel de consumer als de provider over goed functionerende stubs. Deze stubs valideren of de uitgevoerde testen voldoen aan de overeengekomen specificaties uit het contract. Faalt de validatie… en daarmee de test? Dan hebben de consumer en provider met het contract dus een overlegmiddel om op terug te vallen.”

Met welke tool stel je het contract op? 

“Het contract zelf maak je in een tool genaamd PactFlow. Dit is momenteel de enige tool waarmee je bidirectional kunt testen”, zegt Peter Geurtsen. Het is belangrijk om bidirectional te testen, omdat dan zowel de consumer als de provider hun eigen (functionele) eisen en wensen kunnen vastleggen in het contract. Want pas als beide partijen zich kunnen vinden in de afspraken, vormt het contract een solide basis voor Contract-based testing. Contract-based testing kan je ook op twee andere, minder effectieve manieren inrichten: consumer driven en provider driven. Deze manieren kunnen echter in specifieke situaties goed voldoen. Let er bij het opstellen van het contract dus op dat jouw testmethode voldoet aan de specifieke omstandigheid. Kies voor bidirectional als je wilt dat beide partijen hun testspecifieke wensen kunnen verwerken.”

Welke programmeertalen en applicaties worden ondersteund met Contract-based testing en hoe werkt PactFlow in de dagelijkse praktijk? Test Automation Engineers Mandar Thamke en Omkar Khatavkar gaan daar in de QX Day-presentatie over ‘Contract-based testing, create your first contract’ uitgebreider op in aan de hand van een Contract-based testing-demo.
 

Kijk hier de presentatie terug