Ben je van plan om je ESB integratielaag te migreren naar de cloud? Of plant u gewoon een upgrade naar een nieuwe release? Dan is dit misschien iets voor jou:
Als ik dit onderwerp met klanten bespreek, krijg ik vaak reacties als deze:
“Hoe test je je integratiestromen/processen?”
“Saai, laten we ons richten op de implementatie.”
“Waarom? In ieder geval onbetrouwbaar omdat de aangesloten systemen vaak niet beschikbaar zijn”
“We hebben al tientallen integratiestromen, waarom zou ik daar nu mee beginnen?”
“ESB processen zijn verouderd en het is niet de moeite waard om te investeren in testen”.
Om eerlijk te zijn had ik een soortgelijke instelling toen ik aan mijn carrière begon. Maar ik heb mijn les geleerd.
Onlangs hebben we verschillende upgrade- en migratieprojecten opgeleverd. De meeste projecten waren nog helemaal niet getest toen we begonnen. Sommige klanten wilden niet investeren in het schrijven van testcases voor de bestaande integratiestromen.
“Wat heeft het voor zin om dat te doen als je de oplossing al aan het upgraden of vervangen bent? “
Zoals je je kunt voorstellen, kregen we aan het begin van de projecten vaak veel weerstand tegen het investeren van tijd en middelen in testen. Vooral als het niet om een upgrade maar om een migratie ging. Maar vroeg of laat zagen we bij elk project de voordelen.
Wanneer organisaties overstappen naar de cloud of simpelweg upgraden naar een nieuwe release, is het testen van de applicatie-integratielaag een kritieke stap in het migratieproces. Deze laag is verantwoordelijk voor de integratie van applicaties en services die in verschillende omgevingen worden gehost. Het is belangrijk om ervoor te zorgen dat deze componenten met elkaar communiceren zoals verwacht. Voor een succesvolle migratie moeten engineers de tijd nemen om de integratielaag grondig te testen.
De overstap naar infrastructure-as-code en geautomatiseerde implementaties wordt de de-facto standaard. In onze projecten hebben we dit toegepast op de integratielaag samen met geautomatiseerd testen. Er zullen altijd integratietests en handmatige tests nodig zijn. Deze tests zijn echter meestal tijdrovend en duur. Vaak ook foutgevoelig tot op zekere hoogte.
Daarom is het erg belangrijk om problemen vroeg in het proces op te vangen en op te lossen. Integratieflows moeten worden behandeld als programmeerbroncode en moeten bij elke wijziging worden getest. Klinkt logisch… niets nieuws… correct. Je zou kunnen zeggen dat ik gewoon het voor de hand liggende zeg en daar ben ik het niet mee oneens. De realiteit is echter dat deze logische dingen vaak niet worden geïmplementeerd.
Voorbeeld:
Het bovenstaande voorbeeld triggert een GitHub Actions workflow op elke commit+push. De integratieflows worden gebouwd en dan automatisch ingezet in een gecontaineriseerde omgeving. Deze omgeving wordt aangemaakt als onderdeel van de CICD workflow en vervolgens gebruikt tijdens het uitvoeren van de tests.
Wat is er nodig om dit voor elkaar te krijgen voor jouw integratiestromen en welke factoren dragen bij aan het succes:
- Kwaliteit testgegevens
- Geautomatiseerde testgevallen
- Mocking van aangesloten systemen
- Testdekking
Al deze factoren zijn belangrijk en sommige zijn gemakkelijker te bereiken dan andere. We gebruiken ons eigen framework om automatisch de testgegevens van een bepaalde omgeving te verzamelen en te testen. Deze gegevens zijn dan al klaar om gebruikt te worden voor testen en mocking.
Test-cases worden dan geschreven in Java (wat tot op zekere hoogte ook geautomatiseerd kan worden, voor eenvoudige asserties) en ze hergebruiken de verzamelde gegevens.
Het verwachte resultaat van een gegeven integratie-flow-stap kan worden nagebootst als de backend-systemen niet beschikbaar zijn. Het framework kan het verzamelde resultaat van de stap gebruiken in plaats van de backend aan te roepen. Als alternatief (of als aanvulling) kunnen de testgevallen worden uitgevoerd tegen een bepaalde omgeving met verwachte testresultaten per omgeving. Dit betekent dat je dezelfde testgevallen kunt gebruiken, maar dat bijvoorbeeld tijdens de build sommige systemen worden gemockt en vervolgens tijdens een test tegen een hogere omgeving geen stappen worden gemockt. De testgevallen blijven onaangeroerd.
Als de testgevallen eenmaal zijn geschreven en succesvol zijn uitgevoerd, is de vraag: “Hebben we alles gedekt?”
Testdekkingsrapporten helpen hier enorm bij en laten het percentage van de algehele dekking zien (per integratiestroom/ESB-proces) en per testscenario.
Bovendien kun je in de gegevens duiken en een lijst krijgen van stappen die momenteel nog niet getest zijn, zelfs van aangeroepen subprocessen. Dit maakt het gemakkelijker om extra testgevallen te identificeren die geschreven moeten worden.
Als een wijziging resulteert in een succesvolle build (inclusief tests) kan het pakket worden vrijgegeven en/of uitgerold.
Lagere omgevingen kunnen automatisch worden uitgerold met behulp van je CICD-pijplijn.
Continuous Delivery-omgevingen met Ansible, Jenkins/Github-Actions, GitHub & AWS zijn een geweldige combinatie om dit te bereiken.
Hiermee kunnen omgevingen reproduceerbaar worden aangemaakt zonder enige handmatige interactie.
Voor hogere omgevingen raden we aan dezelfde aanpak te gebruiken, maar de implementatie met vrijgegeven versies handmatig te starten. Zonder menselijke tussenkomst op de servers is dit minder foutgevoelig en is de doorlooptijd korter.
conapi ESB/Integratie testkader:
- Automatisch test- en Mocking-gegevens verzamelen
- Mocking van integratiestroomstappen (d.w.z. backend simuleren)
- Dekkingsrapport (percentage, lijst met niet-geteste stappen)
- Klaar voor CICD
- Asserties bij testuitvoer
