Auteur: Gilbert Smulders ● gilbert.smulders@viqit.nl
Op mijn opdracht lopen we momenteel tegen een aantal problemen aan, nu we microservices aan het implementeren zijn. Een element hierin is het testen van deze services. Ik was daarom op zoek naar ideeën van anderen hoe je dit moet aanpakken en waar je specifiek op moet letten. In mijn zoektocht liep ik tegen een video aan van iemand die daar een visie op had. Net op dat moment kwam ook de reminder voorbij voor mijn terugkerende video review bijdrage voor het TNN. Vandaar nu deze video in de review.
De spreker
Katherine Stanley is een softwareontwikkelaar bij IBM. Zij is nog vrij nieuw in het vak, maar al wel erg actief met microservices en het twitteren en presenteren hierover. Onder andere op conferenties voor ontwikkelaars zoals DevoxxUK, OSCon en JFokus. Ook is zij een van de auteurs van het boek Microservices Best Practices for Java. Je kunt haar volgen via haar Twitter account @KateStanley91.
De presentatie
Katherine begint haar presentatie op JFokus met een uitleg over wat microservices zijn. Dit is wel handige achtergrondinformatie alvorens zij start met haar idee over het testen van microservices. Het grootste deel van haar presentatie gaat over het testen van die microservices. Daarbij onderscheidt zij vijf soorten testen. De unittesten, componenttesten, contracttesten, integratietesten en end-to-end-testen.
De unittesten verschillen niet zo veel van de unittesten voor monolieten, zoals zij dat noemt. Echter, aangezien de functionaliteit van de losse unit zo klein is geworden, vraagt zij zich af of deze testen nog wel nuttig zijn. Misschien handiger om meer component testen te doen. Deze componenttesten kun je vergelijken met de bij ons beter bekende unitintegratietesten. Daarbij wordt de buitenwereld als een ‘test service’ gesimuleerd om de eigen functionaliteit te kunnen testen op basis van het verwachte gedrag van die buitenwereld. Na de componenttest adviseert Katherine een contracttest. Deze contracttest controleert niet echt de eigen functionaliteit, maar meer de communicatie tussen partijen. Welke input- en output-attributen worden er onderling gecommuniceerd en ontstaan er geen fouten in de communicatie? Na deze drie testen adviseert zij om de andere twee testen op te nemen in de build pipeline. Immers, voor zowel de integratietest als de end-to-end-test ben je afhankelijk van de juiste versie van de diverse aanpalende systemen. Door deze allemaal in een soort staging omgeving beschikbaar te stellen, kunnen de diverse applicaties getest worden met elkaar. Voor de integratietesten stelt zij voor om alleen de basis success- en error-scenario’s te testen. Daarbij wordt niet alleen de integratie met andere applicaties/services getest, maar ook de interactie met diverse data stores. De integratietest focust niet op het eigen gedrag. Daar zijn de unittest en contracttest voor. De end-to-end-test is tot slot eigenlijk niet meer dan een sanity check en om externe requirements te checken. Ook worden hier de UI-testen geïntegreerd.
Ze sluit haar presentatie af met de conclusie dat er op het gebied van het testen van microservices nog veel valt te ontdekken. Zij adviseert om in kleine stapjes te groeien en de testen aan te passen aan het ontwikkel- en opleverproces. Ten slotte verwijst ze nog naar de site van Martin Fowler voor aanvullende informatie.
Mijn visie
Naar mijn idee is dit een aardig verhaal vanuit een ontwikkelaar. Vanuit testperspectief verwacht ik echter wel wat meer. Zo mis ik de risico’s en hoe deze af te dekken. Vooral bij het stuk over integratietesten en end-to-end-testen begin ik me zorgen te maken. Immers, één van de zaken waar wij in de praktijk tegenaanlopen is de afhankelijkheid van de diverse services onderling. Tel daarbij de verschillende versies die van al die services in omloop zijn bij op. Hoe ga je dit managen? En hoe weten we dat we de juiste zaken met elkaar testen?
Zo gebeurt het bij ons in de praktijk regelmatig dat andere services ineens niet meer beschikbaar zijn. Of dat er versies draaien waarin de benodigde functionaliteit nog niet beschikbaar is. Of dat services juist ineens anders functioneren waardoor onze service ook niet meer goed functioneert. Juist over de integratie maak ik me zorgen bij microservices. Dat een component op zichzelf goed functioneert en dat hij voldoet aan alle contract afspraken, dat geloof ik wel. Maar hoe bewaken we dat functionaliteit over alle microservices heen gewaarborgd is en blijft? Ik denk dat we daar ons hard voor moeten maken!
Voor testers die op zoek zijn naar een beginnende testaanpak voor microservices is deze presentatie een aardige start. Maar wil je echt de risico’s goed afdekken, moet je veel verder gaan dan wat Katherine beschrijft! Heeft iemand nog goede tips? Dan hoor ik ze graag.
Bekijk de video hier
NieuwsMagazine