{"id":11209,"date":"2025-08-19T08:23:26","date_gmt":"2025-08-19T08:23:26","guid":{"rendered":"https:\/\/www.dignitas.nl\/?p=11209"},"modified":"2026-01-05T16:36:48","modified_gmt":"2026-01-05T16:36:48","slug":"contract-testing","status":"publish","type":"post","link":"https:\/\/www.dignitas.nl\/contract-testing\/","title":{"rendered":"Contract Testing: Integratieproblemen vroeg opgelost.\u00a0"},"content":{"rendered":"

Schrijver: Max van Deursen, Software Engineer<\/em><\/p>\n

Contract Testing: Integratieproblemen vroeg opgelost.\u00a0<\/strong><\/h1>\n

Laatst werkte ik aan een nieuwe koppeling tussen mijn app en een extern systeem om klantdata op te halen. Op basis van de API-specificatie bouwde ik de integratie, testte alles lokaal met een fake implementatie, en het leek perfect te werken. Mijn code ging door de review, ik zette \u2019m live\u2026 en toen\u2026 BAM, ging het mis. De echte API reageerde anders dan verwacht.<\/p>\n

Waarom zag ik dit niet eerder? Was mijn fake implementatie te beperkt? Of week de provider af van de specificatie, of was dit allebei zelfs het geval?<\/p>\n

Die fout zette me aan het denken: dit moet beter kunnen. In deze blogserie neem ik je mee in de wereld van contract testing<\/b>; een techniek waarmee je dit soort integratie-issues al vroeg kunt tackelen. Met contact testing vind je deze gevallen al voordat de systemen \u00fcberhaupt direct met elkaar verbonden zijn. Hoe eerder je de fouten vindt, hoe minder impact ze maken.<\/p>\n

De provider en de consumer<\/b>
\nIn contract testing worden de systemen die met elkaar communiceren vaak de provider<\/i> en de consumer<\/i> genoemd. De provider is het systeem wat functionaliteit en data aanbiedt die andere systemen kunnen gebruiken. Een voorbeeld hiervan is een REST API waarmee je productgegevens kunt opvragen. De consumer is het systeem dat de provider uitvraagt om zijn werk te doen. Een webshop die productgegevens toont is een voorbeeld van zo\u2019n consumer.<\/p>\n

De afspraken<\/b>
\nDe consumer wilt weten hoe deze met de provider kan communiceren en wat deze aanbiedt. Ook heeft de consumer behoefte om goed te weten waar de provider aan dient te voldoen.<\/p>\n

Om vervelende verrassingen te voorkomen bij het koppelen van de systemen is het handig om deze functionaliteit en behoeftes van de provider en consumer vast te leggen. In het geval van communicatie met behulp van HTTP is de OpenAPI Specification (OAS)<\/span><\/a> een veelvoorkomend formaat om dit te documenteren. Met de OAS kan je een HTTP API omschrijven zonder dat er toegang tot de broncode, documentatie, of netwerkverbinding nodig is. Deze specificatie biedt de provider een handvat om zijn implementatie in te richten. Ook de consumer kan beginnen met ontwikkelen op basis van deze specificatie.<\/p>\n

Afspraken nakomen<\/b>
\nTijdens het ontwikkelen van zowel de consumer als provider wordt er gekeken naar de OAS. De provider zorgt dat zijn REST endpoints overeenkomen met de OAS. De consumer maakt een fake implementatie van de provider om zo de reactie van zijn systeem te testen.
\nDeze ontwikkeling heeft de beste intenties, maar toch kunnen er fouten voorkomen. Hier komt contract testing om de hoek kijken. Deze tests bevestigen dat de provider zich aan de afspraken houdt en dat de implementatie van de consumer alleen de OAS gebruikt.
\nGelukkig bestaat er software die ons bij deze opzet kan helpen. Ik heb goede ervaringen met de tool Specmatic<\/span><\/a> om dit allemaal (en meer) mogelijk te maken en dit is dan ook de tool die ik in deze blogreeks gebruik.<\/p>\n

Specmatic<\/b>
\nSpecmatic is software waarmee je zowel de consumer als provider kunt contract testen. Bij het testen met behulp van Specmatic staat de OAS centraal. Voor de consumer biedt Specmatic een \u201cSmart Mock\u201d server aan. Deze server kan de consumer gebruiken als fake implementatie van de provider. De reacties die deze server geeft worden aan de hand van de OAS gegenereerd. Ook biedt Specmatic de mogelijkheid zelf voorbeelden mee te geven als reactie. Voordat deze worden gebruikt, worden deze voorbeelden eerst gevalideerd aan de hand van de OAS. Hierdoor kan de consumer zeker zijn dat zijn implementatie overeenkomt met de OAS en aan de hand van de voorbeelden kunnen alle edge cases worden afgedekt.<\/p>\n

Specmatic kan ook de provider testen aan de hand van de OAS. Net zoals bij de consumer genereert Specmatic zelf testen op basis van de OAS. Ook hier biedt Specmatic de mogelijkheid om voorbeelden mee te geven die moeten worden getest. Hierna worden de antwoorden van de provider geverifieerd of zij overeenkomen met de omschreven structuur in de OAS.<\/p>\n

Wat nu?<\/b>
\nOmdat zowel de consumer als de provider gebruik maken van dezelfde OAS en hier beide op getoetst zijn, zal de daadwerkelijke communicatie ook volgens dezelfde specificatie verlopen. Hiermee ben je zeker van het functioneren van jouw applicatie, zelfs zonder dat de echte API is gebruikt! Daarnaast kan je met de voorbeelden specifieke gevallen nabootsen en zo ook de edge cases van jouw applicatie testen.<\/p>\n

Met contract testing weet je zeker dat systemen doen wat ze beloven, nog voor ze echt met elkaar praten. Dat voorkomt verrassingen en maakt samenwerken aan API\u2019s betrouwbaarder en sneller. Wil je weten hoe je dit voor een consumer opzet? In de volgende blog uit deze reeks neem ik je mee om dit met behulp van Specmatic te implementeren. Zo kan jij er ook binnen jouw project voor zorgen dat je voordeel van Specmatic hebt!<\/p>\n

Overzicht blogreeks<\/b>
\n19 augustus 2025 – Contract Testing: Integratieproblemen vroeg opgelost<\/a>
\n20 oktober 2025 \u2013 <\/a><\/span>Contract Testing voor consumers: aan de slag met Specmatic\u2019s Smart Mocks
\n<\/a>23 december 2025 \u2013 Contract Testing voor providers; test je API met Specmatic<\/a>
\n17 februari 2026 \u2013 Beheer van OpenAPI specificaties en veilig wijzigen met Specmatic<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Schrijver: Max van Deursen, Software Engineer Contract Testing: Integratieproblemen vroeg opgelost.\u00a0 Laatst werkte ik aan een nieuwe koppeling tussen mijn app en een extern systeem om klantdata op te halen. Op basis van de API-specificatie bouwde ik de integratie, testte alles lokaal met een fake implementatie, en het leek perfect te werken. Mijn code ging … <\/p>\n

Continue reading “Contract Testing: Integratieproblemen vroeg opgelost.\u00a0“<\/span><\/a><\/p>\n","protected":false},"author":4,"featured_media":11218,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[176],"tags":[],"class_list":["post-11209","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-engineering"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/posts\/11209","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/comments?post=11209"}],"version-history":[{"count":7,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/posts\/11209\/revisions"}],"predecessor-version":[{"id":11453,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/posts\/11209\/revisions\/11453"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/media\/11218"}],"wp:attachment":[{"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/media?parent=11209"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/categories?post=11209"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dignitas.nl\/wp-json\/wp\/v2\/tags?post=11209"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}