Ketentesten: werkt het proces over alle systemen heen?

Wat is een ketentest?

Bijna elk proces loopt door meer dan één systeem. Een bestelling gaat van de webwinkel naar een orderservice, een betaalprovider, een magazijnsysteem en de facturatie. Elk van die systemen wordt door het eigen team getest. Een ketentest kijkt naar de keten als geheel: één bestelling erin aan het begin, gevolgd tot het eind, met een controle bij elke overdracht.

Ketentesten is vooral in Nederland en België een gangbare term, vaak bij overheid en grote organisaties waar systemen van verschillende leveranciers moeten samenwerken. Internationaal heet het meestal end-to-end testing over systemen heen, of chain testing.

Een ketentest afbakenen

1. Kies het proces, niet de systemen: ‘een klant bestelt, betaalt en krijgt een factuur’, niet ‘test de factuurservice’.

2. Teken de keten: welke systemen, in welke volgorde, en wat geeft elk systeem door aan het volgende (een id, een bericht, een bestand, een e-mail)?

3. Bepaal per overdracht waar je die kunt zien: een API die je kunt uitlezen, een status die je kunt opvragen, een e-mail in een testinbox.

4. Spreek af in welke omgeving de keten draait, en dat alle systemen daarin versies zijn die bij elkaar horen.

5. Leg vast welke eindtoestand bewijst dat de keten werkt, en welke toestanden bewijzen dat hij breekt: blijft hangen op ‘in behandeling’, er komt geen factuur.

Waarom ketentesten lastig is

• Testdata in elk systeem. De klant moet bestaan in elk systeem van de keten. Laat de test zijn eigen data aanmaken aan het begin, met unieke namen, in plaats van te leunen op records die iemand ooit met de hand heeft gemaakt.
• Asynchrone stappen. Overdrachten lopen vaak via een wachtrij, een batch of een webhook. Vraag een status herhaaldelijk op tot de verwachte toestand er is, met een tijdslimiet, in plaats van een vaste tijd te wachten.
• Toegang tot elk systeem. Ieder systeem heeft zijn eigen inlog. Een ketentest heeft per systeem en per rol een testaccount nodig, buiten de testcode bewaard.
• Omgevingen die uit de pas lopen. Eén systeem op een nieuwere versie en de keten breekt voor iedereen. Wie de ketentest na elke deploy draait, ziet welke wijziging het was.
• Eigenaarschap. Faalt een ketentest, dan denkt elk team dat het aan een ander systeem ligt. Maak de falende stap en het antwoord dat erbij hoort voor iedereen zichtbaar.

Een ketentest automatiseren

Handmatige ketentesten worden meestal vlak voor een grote release gedaan, kosten dagen en zijn bij de volgende release alweer verouderd. Geautomatiseerd worden ze een controle die na elke deploy en op een vast interval draait. Daarvoor heb je nodig:

• Elk systeem bereikbaar via een API vanaf de plek waar de tests draaien, of via een agent binnen het netwerk.
• Eén plek die per omgeving de adressen van alle systemen kent, zodat dezelfde keten op test én acceptatie draait.
• Stappen die waarden uit het antwoord van het ene systeem meegeven aan de aanroep van het volgende.
• Duidelijke uitkomsten: welke stap in welk systeem faalde, en met welk antwoord.

Ketentesten met Journey Lanes

Een project in Journey Lanes kan per service een repository hebben. Op een omgeving krijgt elke service zijn eigen adres, en een stap gaat naar de service in wiens code het endpoint staat. Zo loopt één flow door alle services van de keten. Stappen geven waarden door met {{stap-id.pad}}, een leesstap kan herhalen tot het volgende systeem het resultaat laat zien, en e-mailstappen lezen wat een systeem verstuurde uit een testinbox (live environments).

In dit voorbeeld maakt de ene rol de gegevens aan waarmee de andere rol daarna werkt, dus de flow controleert precies die overdracht. De regelengine leest ook Nederlandse beschrijvingen; het voorbeeld is Engels omdat de voorbeeld-API Engelstalig is.

Systemen in een afgeschermd netwerk bereik je via een relay agent die je zelf binnen dat netwerk draait. Twee omgevingen zijn stap voor stap te vergelijken, en de keten draait na elke deploy en op een interval. Journey Lanes roept HTTP- en gRPC-API’s aan: een systeem zonder API om aan te roepen of uit te lezen, controleer je via een systeem dat er wel een heeft.