Outils de test d'unité Tibco

Question

Est-ce que quelqu'un sait quels outils de test unitaire sont disponibles lors du développement de processus Tibco?

Au cours des prochains mois, je vais travailler sur un projet Tibco et j'essaie de trouver des cadres de tests unitaires qui pourraient rendre le travail plus facile à construire avec une approche TDD. Jusqu'ici, le seul que j'ai pu localiser s'appelle BWUnit. Cela semble correct mais c'est actuellement en version bêta et son logiciel commercial. Si possible, j'aimerais utiliser un outil open source, mais tant que je serai capable de faire du bon travail, je serais heureux.

Alors, est-ce que quelqu'un connaît d'autres outils de tests unitaires pour le développement de Tibco?

En outre, quelqu'un a-t-il une expérience avec BWUnit? A quel point est/était-ce utile?

Answer 1

Pour les projets BW, j'ai préparé mon propre cadre de test unitaire basé sur les processus BW lui-même. Les tests automatisés et les validations sont donc codés dans le projet TIBCO lui-même.

Pour les projets AMX, je recommande SOAPUI pour les tests automatisés de vos services. Cependant, j'ai codé tous les tests unitaires dans le langage sous-jacent, dans mon cas Java, en utilisant JUnit. Les classes d'implémentation sous les composants se réfèrent directement dans les tests unitaires, en ignorant le code AMX faisant la messagerie.

Answer 2

Il existe un ancien cadre appelé Raccoon construit au-dessus de Tibco ActiveEnterprise.

Il dispose d'un composant pour les tests unitaires appelé UiTest axé sur la messagerie RendezVous.

Il ne semble pas avoir trop d'activité ces derniers temps, cependant.

Answer 3

J'ai eu beaucoup de succès en créant une couche d'interface de savon pour chacun de mes processus (en prenant les mêmes arguments) et en utilisant SoapUI pour faire tous les tests pilotés à partir de quelques tables de base de données.

Edit:

Ce que je décrit est à peu près comment BWUnit fonctionne: (. Peut-être avec un peu de travail manuel, mais même concept), il crée une interface de service Web autour de chacun de vos processus

entrée de test (SoapUI) -> testable Interface (savon/sme/etc) -> processus existant -> Quitter Interface -> assertions (SoapUI)

Vous pouvez faire le test au sein TIBCO lui-même, avec des fichiers, RV, JMS, ou n'importe quelle entrée pour ce matt heu, sauf que vous écrivez vous-même tout le code d'assertion de test plutôt que d'utiliser un outil existant qui l'a intégré. Vous pouvez ensuite compter sur SoapUI pour générer tous vos rapports JUnit etc.

Si vous voulez vraiment obtenir fantaisie, vous pouvez ajouter une cible soapui à votre script de build pour inclure les tests unitaires et/ou les tests fonctionnels pour chaque build une fois déployé.

Answer 4

Déopends sur le protocole utilisé (ce qui est utilisé). Racoon et SoapUI ont été mentionnés. Avec eux, vous pouvez tester sur un niveau "par module". C'est un test de composant ou de système. Particulièrement utile pour les tests de performance. Cependant, c'est la façon la plus courante de tester les composants tibco.

Je vais jeter un oeil à la BWUnit, l'air intéressant et intégré avec les serveurs CI (j'ai construit un outil similaire dans un projet). Une faille de cette approche peut être que les systèmes TIBCO sont généralement composés de différents outils et pas seulement BW, ce qui signifie que les composants Java, les serveurs C++ et ainsi de suite sont utilisés pour l'ensemble du système.

Il y a aussi un outil commercial appelé GHTester (http://www.greenhatconsulting.com/ghtester/)

Si vous utilisez RV vous pouvez jeter un oeil à http://www.rvsnoop.org/ pour capturer les messages dans un format rejouable gratuitement (outil OSS que j'ai commencé)

Answer 5

Avec BW-test, vous pouvez pratiquer TDD et ajoutez vos projets à votre CI Check it out sur http://nicosommi.com/?p=209

Il est open source

Answer 6

Essayer de faire une méthodologie comme TDD en utilisant l'interface utilisateur de savon ne serait pas très efficace. J'ai utilisé ceci pour BW et vous n'obtenez pas le même niveau de granularité et de confort à partir d'une suite complète de tests unitaires. BWUnit est un bon outil, et si vous avez une bonne relation avec vos gars de TIbco PSG, vous pouvez obtenir TibUnit qui est un Ware PSG comme CLE.

Nous avons également mis au point un plan d'utilisation d'un framework de test unitaire externe tel que .net, puis utilisons un modèle de contrôleur pour échanger des processus à l'aide du drapeau de remplacement de processus dynamique. Alors esentaially nous aurions un canal de commande qui dit quelque chose comme

Contrôle - Processus 1 Remplacer -/processus/SomeProcess.process - Processus 2 Remplacer {Blank}

donc dans votre test unitaire vous pourriez dans votre configuration appeler BW en utilisant votre canal de contrôle (EMS ou HTTP) et lui dire de charger un processus différent. Bien que cela fonctionne encore un hack en raison des fonctionnalités limitées de Designer.

Nous avons également regardé Service Grid et BWSE et cela ne semblait pas nous donner plus. En fait un peu plus limitant.

Answer 7

IBM RIT est un très bon outil pour travailler sur ce genre de scénarios, il peut vous aider à affirmer différents scénarios et aussi pour évaluer la couverture de code.

Answer 8

Je recommande IBM RIT. il fait partie de la pile IBM RTW. Vous pouvez l'utiliser facilement dans les modèles de livraison TDD et CI/CD.