Trendsz, Test engineering, Testadvies, Testautomatisering, Tooling

In een architectuur met vele gedistribueerde services is het soms onmogelijk om de onderlinge werking van deze services te garanderen. Hoe test je de onderlinge werking en hoe garandeer je dat services niet falen in productie? Contract-based testen is een fundamentele manier om dit probleem aan te pakken. Het vertelt je of twee applicaties met elkaar kunnen praten zonder dat er een end-to-end omgeving nodig is. In een reeks van blogartikelen leg ik uit wat contract-based testen is, waarom je het gebruikt en hoe de processen werken.

Definitie contract-based testen

[Contract-based testing is ensuring] that … applications will work correctly together by checking each application in isolation … [against] a shared understanding that is documented in a contract. (bron)

Bij contract-based gaat het dus om het testen van volledige applicaties. Dit wordt over het algemeen beschouwd als een taak voor end-to-end tests op een end-to-end-omgeving die duur is en bovendien niet altijd beschikbaar. Bij contract-based tests, testen we in plaats daarvan de volledige applicatie in isolatie. We hebben geen server of specifieke omgeving nodig om te testen. We kunnen de testen dus gewoon op onze eigen PC uitvoeren.

De context van REST-API’s

Contract-based-testen wordt vaak in verband gebracht met REST-API’s, maar daar is het niet toe beperkt. De principes van contract-based testen gelden even goed voor andere integratieprotocollen zoals SOAP, MQ en Kafka. Er wordt dus geen onderscheid gemaakt tussen protocollen. Contract-based testen is een manier om na te denken over het waarborgen van de kwaliteit van de integratie tussen applicaties. Of, eenvoudiger gezegd: contract-based testen is een testparadigma. In deze blogreeks gebruik ik voor de eenvoud alleen REST API gebaseerde voorbeelden.

Contracten als gedeeld begrip

Zoals de naam van het paradigma al aangeeft, is deze benadering van testen sterk afhankelijk van contracten. Een contract is de documentatie van een applicatie-interface die dient als het gedeelde begrip tussen de interface-aanbieder en de consumers.

Door dit gedeelde begrip te gebruiken, kunnen we allerlei interessante dingen doen. Het contract – ons gedeelde begrip – is alleen nuttig als het voldoet aan alle volgende principes.

Een contract …

  1. Is de enige bron van waarheid voor de interface
  2. Bevat alles wat je nodig hebt om de interface te begrijpen en te gebruiken
  3. Bevat alle mogelijke statussen van de interface
  4. Is leesbaar voor zowel mensen als machines

"Contract-based testen is een manier om na te denken over het waarborgen van de kwaliteit van de integratie tussen applicaties."

De eerste drie principes kunnen bekend voorkomen bij degenen die werken met formalized requirement documents. Het vierde principe daarentegen, opent veel interessante deuren. Het zorgt ervoor dat onze interface requirements voor alles en iedereen leesbaar zijn. Hiermee overbruggen we de kloof tussen business requirements en testautomatisering.

Het overbruggen van de kloof tussen de business- en de ontwikkelingscyclus van applicaties is geweldig voor het verkrijgen van snelheid en nauwkeurigheid bij het ontwikkelen van nieuwe functionaliteiten. Contract-based testen doen dit door het enige ‘single-source-of-truth-requirement-document’ op te nemen als een fundamenteel onderdeel van de tests voor zowel de interfaceproviders als hun afnemers.

Benaderingen

Er zijn twee manieren om contract-based testen te benaderen. Ze onderscheiden zich door wie het contract schrijft. Beide benaderingen werk ik uit in deel 4 van deze blogreeks, maar hieronder alvast een voorproefje van hoe deze benaderingen werken.

Provider driven contract-based testen

In de ‘provider driven’ aanpak schrijft de aanbieder het interfacecontract. De aanbieder zorgt ervoor dat hun interface-implementatie overeenkomt met het contract voordat het contract gedeeld wordt met de afnemers. De gebruikers van de interface gebruiken het contract vervolgens om hun tests te verbeteren.

Consumer driven contract-based testen

In de ‘consumer driven’ aanpak schrijft de afnemer een interfacecontract. Op deze manier dicteert de afnemer de functionaliteiten van de interface. De afnemer zorgt ervoor dat hun applicatie alle kenmerken van het contract kan verwerken voordat ze het contract met de aanbieder delen. De interfaceprovider gebruikt het contract vervolgens om ervoor te zorgen dat de interface alle door de afnemer gedefinieerde functies kan leveren.

Conclusie

Contract-based testen is een testparadigma voor het testen van volledige applicaties waarvoor geen speciale testomgeving nodig is. Het is sterk afhankelijk van de voor mensen en machine leesbare ‘requirement documents’, ook wel contracten genoemd. Hiermee kan het paradigma de kloof tussen de business en testautomatisering overbruggen.

Er zijn twee manieren om contract-based testen te benaderen. Later ga ik in op hoe deze benaderingen precies werken. In deel 2 leg ik uit waarom we zo min mogelijk moeten willen testen op end-to-end omgevingen. Daarbij geef ik een aantal concrete problemen die we tegenkomen als we van end-to-end testen afstappen.

Schrijf je in voor
de nieuwsbrief

werkenbij overall

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz