Hero imageMobile Hero image
  • LinkedIn
  • Facebook

January 15, 2024

Software-landschappen worden steeds complexere ecosystemen. Hoe zorg je dat de verschillende componenten van deze ecosystemen toch goed samenwerken? Contract-based testing biedt uitkomst. Hiermee kun je als development team zowel de systeemintegriteit waarborgen als potentiële interface-problemen detecteren.

Wat verstaan we onder Contract-based testing en hoe doe organiseer je dat? In deze blog vertelt Peter Geurtsen, Senior Test Manager en Scrum Master bij Sogeti, daar meer over.

Creëer autonomie

AI, CI/CD en ontwikkelen in de cloud – de snelle opeenvolging van technologieën zorgt bij software development teams nogal eens voor verwarring. Hoe kunnen zij die verwarring zoveel mogelijk beperken? “Autonomie is de sleutel. Weet als individu en team waar jouw kwaliteiten liggen en focus je daar op”, zegt Peter Geurtsen. Hoe doe je dat bij end-to-end testing? “Baken je werkzaamheden af. Het is eigenlijk niet nodig om ellenlange discussies te voeren over bijvoorbeeld scoping en testscenarios. Je hoeft immers niet meteen naar de final stage toe te werken. Dat kost bovendien veel resources, want je hebt een dedicated keten omgeving nodig.”

Hoe word je autonoom?

Peter Geurtsen: “Je kunt autonomie creëren door je op verschillende aspecten te richten, zoals welke stubs je nodig hebt. Kijk ook wat je shift-right kunt doen en hoe je end-to-end testen kunt minimaliseren: uiteindelijk hoef je eigenlijk daar maar een beperkte set te testen als je de unit-testen en component-testen eerder in het traject uitvoert. Als je een front-end systeem hebt, kan je ook voor meer autonomie zorgen met een partial chain. Maar de meest efficiënte manier om autonomie te creëren in end-to-end testen, is Contract-based testing.”

Wat is Contract-based testing?

Contract-based testing is een methode die garandeert dat de testen die je autonoom uitvoert, conform de interfacespecificaties zijn. Hoe breng je Contract-based testing in de praktijk? “De consuming-partij, de eigenaar van de applicatie, doet eerst een eigen unit-test tegen zijn eigen stubs. Dat levert input op voor het contract, zoals de specificaties, wat er getest moet worden en extra informatie over de interface. Dat contract wordt vervolgens afgestemd met de provider. Die ziet in het contract hoe de interface werkt en richt zijn eigen stubs ook zo in”, legt Geurtsen uit. “Daarna kan je de interface loskoppelen en gaan testen tegen je eigen stubs. Die valideren dan geautomatiseerd richting het contract: werkt alles zoals we het afgesproken hebben?”

Overlegmiddel

Contract-based testing stimuleert overleg. Geurtsen licht toe: “Faalt een test, dan stap je als consumer of provider naar de andere partij om te achterhalen waar de oorzaak ligt. Maak ik een fout of jij? En wat is de fout? Op deze manier dwingt Contract-based testing je om onderling te overleggen.” Slaagt de test? Dan kan je verder gaan op de manier die jij wil, op het moment dat jij wil. Zo ben je als team in control, niet meer afhankelijk van end-to-end testen en dus autonoom.

Drie principes

Om succesvol contract-based te testen, moet je volgens Geurtsen de volgende drie principes hanteren: “Ten eerste is het contract een single source of truth. Iedereen moet dit accepteren. Daarmee neem je ruis weg en voorkom je fouten als gevolg van miscommunicatie in een later stadium. Ten tweede moet het contract alle informatie over de interface bevatten, zodat iedereen bij één bron alles kan vinden. Ten derde moet het contract opgesteld zijn in logische tekst die iedereen begrijpt, zowel mens als machine.”

Drie types

Er zijn drie types Contract-based testing. Dit kan in de eerste plaats consumer driven zijn: dan ligt het initiatief bij het consuming-systeem. In dat geval test de consumer alleen die delen van een interface die hij nodig heeft. De informatie daarover wordt gegenereerd uit het consuming-systeem en vormt de basis voor je contract. De tweede vorm van Contract-based testing is provider driven. In dit geval neem je informatie over de complete interface op in het contract. Het voordeel daarvan is dat hele interface afgedekt is. Het nadeel is dat het contract vooral technisch wordt en er minder nadruk ligt op functioneel testen. De derde variant is bidirectional Contract-based testing. Hierbij leggen beide partijen hun eigen (functionele) eisen en wensen vast in het contract.

Welk basistype van Contract-based testen kies jij? Dat is afhankelijk van je situatie. In zijn QX Day-presentatie ‘Orchestrating the Power of Contract-Based Testing’ gaat Geurtsen dieper in op de praktische kant van Contract-based testing. Zo vertelt hij onder andere hoe je met deze methode zowel systeemintegriteit kan realiseren als toekomstige problemen kan voorkomen.

Wil je meer weten over Contract-based testen?

Kijk dan de presantatie terug of neem direct contact met ons op.

Bekijk de presentatie hier terug

Marco van Winsen

Marco van Winsen

Head of Quality Engineering & Testing