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 software ontwikkelaar bij IBM. Zij is nog vrij nieuw in het vak. Maar zij is 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 onderscheid zij vijf soorten testen. De unittesten, component testen, contract testen, integratie testen en end-to-end testen.
De unittesten verschillen niet zo veel van de unittesten van de 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 component testen kun je vergelijken met de bij ons beter bekende unitintegratie testen. 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 component test adviseert Katherine een contract test. Deze contract test 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 integratie test 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 integratie testen stelt zij voor om alleen de basis succes 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 integratie test focust zich niet op het eigen gedrag. Daar zijn de unit test en contract test 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 oplever proces. 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 test perspectief verwacht ik echter wel wat meer. Zo mis ik de risico’s en hoe deze af te dekken. Vooral bij het stuk over integratie testen en end-to-end testen begin ik me zorgen te maken. Immers één van de zaken waar wij in de praktijk tegenaan lopen 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.
Bij een contract test wordt het contract niet alleen bij de afnemende partij maar ook bij het team die verantwoordelijk is voor de service. Oftewel bij een andere versie zal de test falen alsmede bij een wijziging van de functionaliteit. Zo niet, is je contract test niet volledig.