SOA-ketentesten: de zwakste schakel

Ik ben betrokken bij diverse soa-test automation-projecten. In veel van deze projecten speelt er naast alle aspecten rond het testen nog iets anders een rol. Voordat je kan beginnen met testen heb je een testomgeving nodig. Dat begint natuurlijk met de nodige hardware en software. Van ijzer, OS tot en met (middleware) software, alles moet aanwezig, geïnstalleerd en geconfigureerd zijn voor je met testen kan beginnen.

Als de applicatie die je gaat testen nu monolithisch is, dan is het opzetten van een testomgeving een klus, maar over het algemeen goed te doen. Als je in een volledig gedistribueerde op soa-principes gebaseerde omgeving een testomgeving nodig hebt, dan is dat wel even een heel ander verhaal. Niet alleen is de hoeveelheid hardware en software die je in een dergelijke omgeving nodig hebt vele malen meer dan in een monolithische omgeving. Het inregelen, configureren en met elkaar verbinden van alle componenten is ook nog eens veel complexer. Het vervelende is dan uiteraard ook nog eens dat het uitvoeren van een integratietest of een ketentest vaak alleen maar zin heeft als alle componenten die hier een rol in spelen allemaal aanwezig zijn en goed (samen)werken. De keten is natuurlijk zo sterk als de zwakste schakel.
Ook hier kan virtualisatie een rol spelen. Zoals het virtualiseren van hardware helpt bij het inrichten van een omgeving (denk aan VMware), zo helpt virtualisatie van de applicatielogica bij het opzetten van een ketentest. Neem als voorbeeld een zojuist ontwikkelde webapplicatie die gebruik maakt van een mainframe via een webservice. Om de webapplicatie te kunnen testen is het mainframe nodig. Door nu de webservice die de verbinding vormt met het mainframe virtueel te maken, is de webapplicatie te testen zonder dat daarvoor een mainframe nodig is. Gebruikelijk is dat ontwikkelaars voor dit doel een stub schrijven, een klein programmatje dat de webservice implementeert en op bij elke vraag een standaard antwoord geeft. Nadeel is dat er totaal geen flexibiliteit in dit antwoord zit en dat als de interface wijzigt je als tester een programmeur nodig hebt om de stub aan te passen. Door het inzetten van een testplatform voor de implementatie van deze virtuele services is het opeens wel mogelijk voor een tester om een flexibele, zelf aan te passen en van logica voorziene service te maken die in de plaats van het mainframe gebruikt kan worden tijdens het testen. Zelfs in een loadtest-scenario is de virtuele service te gebruiken, omdat deze notie heeft van de reactietijd van het mainframe (via een soort zelflerend systeem) kan je een loadtest uitvoeren van de webapplicatie zonder een duur en onhandig mainframe nodig te hebben. Virtuele services beperken zich uiteraard niet tot webservices, allerlei componenten lenen zich ervoor om gevirtualiseerd te worden, denk bijvoorbeeld aan messages queue's, ESB's en databases.
Virtuele services komen in twee smaken: zelflerend aan de hand van een 'record and playback' scenario (ideaal voor services waarvan de achterliggende infrastructuur niet altijd beschikbaar is, zoals een mainframe of een thirdparty service), de tweede variant is een 'service generator', op basis van een interface-beschrijving (bijvoorbeeld een WSDL) wordt een service-implementatie gegenereerd die een tester dan zelf zonder programmeren kan voorzien van logica (een lijst met vaste input en output waardes of een bepaald dynamisch gedrag). Hiermee wordt een keten opeens wel testbaar, terwijl zonder deze voorzieningen de keten heel vaak door de zwakste schakel onderbroken wordt.