"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.
Ben jij geïnteresseerd in contract-based testen?
Luister dan ook onze podcast waarin Sander van Beek en Stephan Dammers in gesprek gaan over dit onderwerp. Sander maakt jou wegwijs in de wereld van contract-based testen en vertelt uitgebreid over zijn ervaringen, wanneer contract-based testen wordt ingezet, de te verwachtte trends en nog veel meer. Je luistert de podcast via ons SoundCloud account.