Automatisch testen van message oriented middelware

[Gerco]

Voor mijn werk implementeer ik een JMS based "message oriented middleware" product. Hierbinnen ontwikkelen we allemaal processen (routeringen van berichten, transformaties, aanroepen naar externe systemen en verschillende andere bewerkingen).

Nu kunnen we dit natuurlijk wel testen door gewoon een berichtje op een queue te zetten en te kijken of dat er op de goede plaats en in het goede formaat weer uitkomt. Dat werkt tot nu toe prima. Ik ben nu alleen bezig met een wat groter project, enkele honderden onderling afhankelijke bericht stromen en dan is dat handmatige gedoe allemaal niet zo handig. Regressie tests kun je dan al helemaal vergeten, kost teveel tijd.

Ik heb dus JUnit ingeschakeld om wat simpele geautomatiseerde tests te doen. Deze doen hetzelfde als de handmatige tests: berichtje inschieten, luisteren op een aantal bekende queues en rapporteren wanneer het bericht ontvangen is en of dat goed was. Dat werkt op zich allemaal prima, maar is niet echt handig om te gebruiken voor mijn niet-Java sprekende collega's, aangezien een JUnit test toch echt in Java geschreven dient te worden.

Heeft er iemand ervaring met het geautomatiseerd testen van dit soort systemen? Unit testen kun je het niet noemen, aangezien de processen niet zonder container te draaien zijn en we dat ook helemaal niet willen. We willen het gehele systeem testen, alle losse componenten zijn al ge(unit) test voor zover dat mogelijk is.

[MisterBlue]

Heb zelf geen ervaring mee, maar misschien is het Fitness framework hiervoor geschikt. Het is mij niet duidelijk wat de rol van je collega's is en wat precies niet handig voor hun is. Moeten ze zelf de automatische test scripts schrijven of doe jij dat voor ze en hoeven zij ze alleen te draaien?
Wil je testen die automatisch kunnen draaien bij een build of wil je het gewoon makkelijker maken voor de testers?

[ Voor 16% gewijzigd door MisterBlue op 08-09-2007 18:46 ]

[Gerco]

MisterBlue schreef op zaterdag 08 september 2007 @ 18:11:
Heb zelf geen ervaring mee, maar misschien is het Fitness framework hiervoor geschikt.

Ik ga er eens naar zoeken, je weet nooit.

Het is mij niet duidelijk wat de rol van je collega's is en wat precies niet handig voor hun is. Moeten ze zelf de automatische test scripts schrijven of doe jij dat voor ze en hoeven zij ze alleen te draaien? Wil je testen die automatisch kunnen draaien bij een build of wil je het gewoon makkelijker maken voor de testers?

Dat zullen ze zelf moeten doen. Ze spreken dan wel geen Java, maar wel XSLT en beheersen de andere technieken die we nodig hebben. Ze zijn vooral bezig om mappings tussen Xml formaten en de routering over de bus werkend te krijgen. Er is ook niet echt sprake van een "build" aangezien er niets gecompiled hoeft te worden. Het gene wat het dichtst in de buurt komt is een uitrol van hun functionaliteit op de centrale ontwikkelserver.

Ze moeten dus test scripts/scenarios kunnen schrijven voor hun functionaliteit (input message, verwachte output op deze en deze queue en niets op die en die queue) en deze kunnen draaien op zowel hun lokale omgeving als op centrale ontwikkel (al wil ik die elke nacht automatisch laten draaien, dus dat is niet zo belangrijk).

[MisterBlue]

Ze moeten dus test scripts/scenarios kunnen schrijven voor hun functionaliteit (input message, verwachte output op deze en deze queue en niets op die en die queue) en deze kunnen draaien op zowel hun lokale omgeving als op centrale ontwikkel (al wil ik die elke nacht automatisch laten draaien, dus dat is niet zo belangrijk).

Je zou nog steeds xUnit kunnen gebruiken, maar dan in een script taal als python of ruby. Doe je ze een keer voor hoe je input bestanden aanspreekt en de output controleert en daarna kunnen ze zelf de testscripts aanpassen zonder afhankelijk te zijn van een java ontwikkelomgeving. Je kunt ook een simpele custom client schrijven in een script taal.

Gezien hun kennis van xml is het gebruik van ant ook een optie. Je parametriseert de code die je gebruikt om te testen zodat ze via ant te scripten zijn. Dan kunnen ze hun eigen testen maken als ant targets.