Als je op het Praegus HQ begint over ‘ketenloos testen’ krijg je vaak een bezorgde blik terug. De ervaring van veel Praegustatoren is nou eenmaal dat je API testen tegen een hoop ‘echte mocks’ (of nog erger, alleen tegen een WSDL) niet voldoende is om vast te stellen of de interactie tussen twee componenten goed zal gaan. De praktijk blijkt toch altijd weerbarstiger.
Natuurlijk: je component goed testen voordat je het test in combinatie met andere componenten is bijna altijd een goed idee. We roepen al jaren dat je functionaliteit het beste zo laag mogelijk in de piramide kan afdekken. Maar dit betekent niet dat je daar alles kunt afdekken. De integratie tussen componenten test je nu eenmaal het beste door die componenten te integreren.
Maar de wereld is wel aan het veranderen. Waar we vroeger een paar grote monolieten hadden, hebben we nu tientallen, zo niet honderden microservices. En naar mate er meer en meer opgesplitst wordt, wordt het verschil tussen de componenttest en integratie of ketentest wel steeds groter; met aan de ene kant 1 component op zichzelf testen en aan de andere kant alle componenten tegelijk testen. Het gat tussen de component- en de integratietest wordt steeds groter. Met meer componenten valt er nu eenmaal steeds meer te integreren. Kan dit niet anders?
Integratie wordt een steeds groter onderdeel van de testpiramide
Het antwoord is een volmondig ja! Bij Praegus Solutions zijn we al een tijdje bezig met wat wij de component-integratietest noemen. Dit houdt in dat we naast unit- en componenttesten, tests draaien voor een component waarbij we in een tijdelijke omgeving ook de directe afhankelijkheden van dat component draaien. In een microservice container based architectuur zoals Docker is dit heel mooi te doen.
Om een typisch voorbeeld te geven. We hebben een wijziging gedaan aan een API. Deze API heeft verbinding met een database en om toegang te krijgen moet je ‘langs’ een authenticatiecomponent. In de component-integratietest starten we dan zowel onze API, als een instantie van de database en een instantie van de authenticatiecomponent. En zo weten we, voordat we überhaupt de nieuwe versie op de testomgeving deployen, dat zowel onze nieuwe authenticatieflow als onze nieuwe SQL queries geïntegreerd werken.
Deze component-integratietest heeft een aantal voordelen. Er wordt meer getest lager in de testpiramide en dus worden bugs eerder gevonden. Daarnaast zit je minder snel anderen in de weg met de uitvoer van deze testen. Verder heb je minder onderhoud aan mocks en meer echte interacties tussen componenten.
Wordt de ketentest dan straks helemaal overbodig? Wij denken nog steeds van niet. Maar in plaats van het testen van integratie, kan de focus verlegd worden naar het testen van bijvoorbeeld configuratie en bruikbaarheid. De ketentest dient aan te tonen dat de gehele applicatie werkt op een productie-achtige omgeving. En hiervoor zou je een stuk minder tests nodig moeten hebben.
Zijn er dan helemaal geen nadelen aan deze manier van werken? Er zijn wel wat punten op te noemen. Technische kennis wordt nog belangrijker. Daarnaast is de initiële configuratie en opzet van een dergelijke testopzet niet triviaal. En natuurlijk hebben je build servers wel wat capaciteit nodig om al deze componenten te kunnen draaien. Maar we denken dat de voordelen opwegen tegen de nadelen. Elke tester weet wat een ellende een ketentest kan zijn.
Dus: ketenloos testen, utopie of onzin? Zoals wel vaker ligt de waarheid ergens in het midden. Met de component-integratietest kun je de ketentest wel weer korter maken en je microservice architectuur optimaal benutten. Ketendun testen. Wie wil dat nou niet? In een vervolg komen we bij je terug met een specifiek implementatievoorbeeld met Testcontainers.
