Al in 2004 schreven Jacolien Vukkink en Thomas Som voor Computable het artikel 'Ketentest is cruciaal'. Dit was vijf jaar geleden, toen was er nog geen sprake van grootschalig gebruik van SOA-principes, laat staan dat de 'cloud' al in beeld was. In het artikel wordt gesproken over een keten van meerdere, door middel van interfaces aan elkaar gekoppelde, systemen.
Hoewel de wereld inmiddels is veranderd, is alles wat er in het artikel staat over het belang van ketentesten op dit moment nog steeds actueel. Sterker nog, de huidige ketens zijn in veel gevallen een stuk groter en complexer geworden dan vijf jaar geleden het geval was en dus zijn ook de ketentests een stuk ingewikkelder geworden.
Er is nu geen sprake meer van gekoppelde systemen, maar van gekoppelde services. Ketens bestaan in steeds grotere mate uit zowel interne als externe componenten en de ketens worden steeds groter. De componenten van een keten worden kleiner maar het aantal componenten neemt hierdoor enorm toe. Waar vroeger ketens bestonden uit een klein aantal grote 'tight coupled'-systemen bestaan ketens tegenwoordig uit tientallen kleine 'loosly coupled'-services. Wel is het zo dat door een verregaande standaardisering en het gebruik van middleware, zoals een ESB, de uitdagingen verplaatst zijn van de techniek van koppelingen naar de inhoud van de berichten die door een keten gaan. Interfaces worden gestandaardiseerd door middel van bijvoorbeeld SOAP en EBXML. Voor de berichten zelf is xml defacto standaard, maar voor de inhoud van de berichten zijn nog weinig algemeen bruikbare standaarden beschikbaar.
Het afstemmen van de data tussen alle betrokken systemen en services is zeer veel werk. De data die het ene systeem gebruikt als inputparameter (bijvoorbeeld een bepaald klantnummer) moet in het andere systeem (als klant) ook aanwezig zijn en daar een bepaalde status bevatten. De betreffende klant met dat klantnummer moet bijvoorbeeld de status 'aangesloten' hebben om het afsluiten van die klant te kunnen testen. Vooral als de ketentesten via een automatische regressietest worden uitgevoerd komt dit heel nauw. En na het uitvoeren van de test zijn er over het algemeen wijzigingen doorgevoerd waardoor de betreffende systemen eerst weer in de oorspronkelijke stand moeten worden gebracht voordat er een volgende test-cycle kan plaatsvinden.
Een deeloplossing voor dit probleem is om, naast het uitvoeren van de eigenlijke test, ook het voorbereiden van de test en het opschonen van de omgeving na afloop van de test zoveel mogelijk te automatiseren door middel van testtooling. Belangrijk hierbij is dan wel dat de testtooling voorzieningen heeft voor toegang tot het filesysteem, toegang tot een database, ftp en JMS vanuit een geïntegreerde omgeving. Dit zijn namelijk de technieken die vaak gebruikt worden bij de voorbereiding- en opschoontaken bij testen. Verder is het belangrijk om zoveel mogelijk externe afhankelijkheden uit de ketentest te elimineren. Hiermee wordt het aantal plekken waar data van moet worden afgestemd teruggebracht tot alleen die onderdelen die rechtstreeks deel uitmaken van de te testen keten.
Traditioneel worden hiervoor stubs gebruikt die door ontwikkelaars zijn gebouwd voor hun eigen testwerk. Deze stubs bevatten daarom vaak maar een beperkte hoeveelheid testgevallen en meestal alleen positieve scenario's en geen uitzonderingen en foutsituaties. Om deze redenen zijn ze slechts beperkt bruikbaar in een ketentest. Beter is het om hiervoor zogenaamde intelligente stubs te gebruiken die door de testers zelf kunnen worden onderhouden. Door test automation software te gebruiken die voorziet in dit soort stubs is het voor testers mogelijk deze net als de testscripts zelf op te zetten en daar waar nodig aan te passen. In deel twee van dit artikel ga ik verder in op het aspect eliminatie van afhankelijkheden in ketentesten.
