Ketenregie, Test engineering, Testadvies, Testmanagement, Testautomatisering, Tooling

Er bestaan verschillende architectuurstijlen die allen voor- en nadelen hebben. Afhankelijk van het doel waarvoor de software wordt gebruikt, past een bepaalde stijl goed of minder goed. Bovendien vraagt iedere architectuur om een andere teststrategie. In deze blog licht ik de verschillende architectuur stijlen – namelijk de monoliet, een SOA, de ESB en een microservice architectuur – toe. Vervolgens zoom ik in op microservices en het voordeel van deze architectuurstijl op testgebied. Ik sluit af met mijn eigen praktijkervaring met het testen van een microservice met behulp van Postman.

De Monoliet

Om te beginnen bestaat er een monoliet als architectuurstijl. Dit is een complex systeem waarbij functionaliteiten en technologieën onderling sterk verbonden zijn. Een monoliet heeft de eigenschap minder modulair te zijn opgebouwd dan andere architecturen. Het is daarom belangrijk om bij regelmatig releasen, continu regressietesten uit te voeren. Bij een monoliet wordt het maken van aanpassingen en uitbreidingen steeds complexer omdat na elke wijziging het systeem als geheel gedeployed moet worden. Bij de minst of geringe aanpassing weet je dus niet of je complete software nog werkt en dus ben je genoodzaakt om alle regressietesten (opnieuw) uit te voeren. Dit maakt onderhoud aan het systeem moeilijker en foutgevoelig.

"Bij de minst of geringe aanpassing weet je dus niet of je complete software nog werkt en dus ben je genoodzaakt om alle regressietesten (opnieuw) uit te voeren."

Service Oriented Architectures

Een veel gebruikte architectuuroplossing om systemen op hoofdlijnen te scheiden, is een Service Oriented Architecture (SOA). Middels de SOA ontkoppel je front-ends (bijvoorbeeld gebruikersinterfaces) met de back-ends (bijvoorbeeld databases). Een SOA zie je in verschillende technische vormen terug, bijvoorbeeld als Enterprise Service Bus oplossingen of als Microservices. Binnen de SOA-laag, ook wel middleware genoemd, is het vrij eenvoudig om nieuwe services toe te voegen of te wijzigen en deze te koppelen met andere front- en back-ends.

De Enterprise Services Bus

De Enterprise Service Bus (ESB) is een oplossing waarbij de service-laag als een apart systeem wordt beschouwd. Hoewel de ESB de eigenschappen van een SOA heeft, is het systeem met services vaak ook monolitisch van aard. Deployment van ESB’s heeft namelijk als gevolg dat er toch regressietesten op de gehele ESB moeten worden uitgevoerd.

Microservices

Een Microservice architectuur bestaat uit verschillende services die los van elkaar functioneren. Beschouw het als een groep kleinere applicaties met een specifieke dienst met een eigen database. Al deze losse services praten met elkaar om uiteindelijk functioneel hetzelfde te doen als de monolithische applicatie. Voor wat betreft het testen, is het erg prettig dat wanneer er een aanpassing gedaan wordt in een microservice, je alleen die betreffende service en de koppeling met andere microservices hoeft te regressietesten. En niet, zoals bij een ESB, de gehele service laag. Of zoals bij een monoliet, het hele complexe systeem. Het is hierdoor ook mogelijk om alvast een onderdeel van het systeem te testen terwijl het geheel nog niet klaar is.

Er zijn verschillende tools die kunnen helpen bij de testwerkzaamheden. Mijn persoonlijke voorkeur gaat uit naar de open source tool Postman. Wanneer je Postman gebruikt hebben andere services daar geen last van. Dit zorgt voor een betere beheersbaarheid.

Poll

Maak jij gebruik van Postman?

Testen van services of UI met Postman

Postman is momenteel een van de meest populaire tools die gebruikt wordt bij API-testen. Een tool als Postman vereenvoudigt het testen en ontwikkelen van een API-workflow. Het is mogelijk om een service te testen door een request in te sturen en een antwoord te ontvangen alsof het van de front-end afkomstig is. Erg handig dus wanneer een service verandert of opgeleverd is, terwijl de front-end misschien nog niet beschikbaar is. Aangezien het een best-practice is om business logica (de complexiteit en regels van het product) in webservices onder te brengen, test je deze logica dan ook makkelijker door ze direct aan te roepen. Je hoeft dus niet meer klik-paden op de front-end te automatiseren en te testen. Ook kun je de geschreven testscripts die je gebruikt op een testomgeving eenvoudig opnieuw gebruiken op bijvoorbeeld een acceptatie omgeving.

Microservices testen met Postman in de praktijk

Via Bartosz ben ik gedetacheerd bij een financiële instelling. Ik houd mij bezig met het testen van een applicatie die het mogelijk maakt om via een online aanvraagformulier een hypothecaire lening af te sluiten voor de aankoop van vastgoed. Er wordt gewerkt met verschillende mircoservices die met elkaar communiceren in verschillende omgevingen. Naast de core is er een front-office, back-office en een mid-office. Ik ben verantwoordelijk voor het testen van de mid-office, terwijl de core en de front-office nog niet klaar zijn. Omdat de gehele keten nog niet af is, test ik met behulp van Postman. Met Postman sturen we bij gebrek aan data fictieve API-berichten, oftewel JSON files, naar de omgeving. Die data creëren we zelf en Postman giet dit in het juiste format. Hierdoor lijkt het alsof er een aanvraag voor een financiering via de core en front-office in de mid-office binnenkomt. En is het voor mij mogelijk om alvast de mid-office en de back-office functioneel te testen, zonder dat de core en front-office daarbij betrokken zijn.

Schrijf je in voor
de nieuwsbrief

Bartosz_Header_004

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz