Tibco Unit Testwerkzeuge

Für BW-Projekte habe ich mein eigenes Unit-Test-Framework basierend auf BW-Prozessen selbst erstellt. Die automatisierten Tests und Validierungen sind also im TIBCO-Projekt selbst codiert.

Für AMX-Projekte empfehle ich SOAPUI zum automatisierten Testen Ihrer Dienste. Allerdings habe ich alle Komponententests in der zugrunde liegenden Sprache, in meinem Fall Java, mit JUnit codiert. Die Implementierungsklassen unter den Komponenten verweisen einander direkt in den Komponententests und umgehen den AMX-Code, der das Messaging durchführt.

Ich habe großen Erfolg damit gehabt, für jeden meiner Prozesse eine Soap-Interface-Ebene zu erstellen (mit den gleichen Argumenten) und SoapUI einzusetzen, um alles zu tun Der Test wurde von einigen Datenbanktabellen gesteuert.

Bearbeiten:

Was ich beschrieben habe, ist, wie BWUnit funktioniert: Es erstellt eine Web-Service-Oberfläche um jeden Ihrer Prozesse herum (vielleicht mit etwas weniger Handarbeit, aber dem gleichen Konzept.)

  

Testeingabe (SoapUI) - & gt; Testbare Schnittstelle (Seife / ems / etc) - & gt; Bestehender Prozess - & gt; Exit-Schnittstelle - & gt; Behauptungen (SoapUI)

Sie können die Tests innerhalb von tibco selbst durchführen, mit Dateien, RV, JMS oder anderen Eingaben, außer dass Sie den gesamten Test-Assertionscode selbst schreiben, anstatt ein vorhandenes Tool zu verwenden, in dem alles integriert ist. Sie können sich dann darauf verlassen, dass SoapUI alle Ihre JUnit-Berichte usw. generiert.

Wenn Sie wirklich originell werden möchten, können Sie Ihrem Build-Skript ein soapui-Ziel hinzufügen, um die Komponententests und / oder Funktionstests für jeden Build nach der Bereitstellung einzubeziehen.

Abhängig vom verwendeten Protokoll (was verwendet wird). Racoon und SoapUI wurde erwähnt. Mit ihnen können Sie auf "pro Modul" -Ebene testen. Das sind Komponenten- oder Systemtests. Besonders nützlich für Leistungstests. Dies ist jedoch die gängigste Methode, tibco-Komponenten zu testen.

Ich werde mir die BWUnit ansehen, sieht interessant aus und integriert sie mit CI-Servern (ich habe ein ähnliches Tool in einem Projekt erstellt). Ein Nachteil dieser Vorgehensweise ist, dass TIBCO-Systeme in der Regel aus verschiedenen Tools bestehen und nicht nur BW, sondern Java-Komponenten, C ++ - Server und so fort für das Gesamtsystem.

Es gibt auch ein kommerzielles Tool namens GHTester ( Ссылка )

Wenn Sie RV verwenden, können Sie sich Ссылка ansehen, um die Nachrichten in einem wieder abspielbaren Format kostenlos zu erfassen (OSS-Tool, das Ich begann)

Der Versuch, eine Methode wie TDD mit Soap UI zu erstellen, wäre nicht sehr effektiv. Ich habe dies für BW verwendet, und Sie erhalten nicht das gleiche Maß an Granularität und Komfort von einer vollständigen Unit-Testsuite. BWUnit ist ein gutes Werkzeug, und wenn Sie eine gute Beziehung mit Ihren TIbco PSG Jungs haben, können Sie TibUnit, die eine PSG Ware wie CLE ist, erhalten.

Wir haben auch einen Plan entwickelt, ein externes Unit-Test-Framework wie .net zu verwenden und dann ein Controller-Pattern zu verwenden, um Prozesse mit dem Dynamic Process Override-Flag auszutauschen. Also hätten wir einen Kontrollkanal, der so etwas wie

Kontrolle    - Prozess 1 überschreiben              - / Prozesse / SomeProcess.process    - Prozess 2 überschreiben              {Leer}

Sie könnten also in Ihrem Komponententest BW über Ihren Steuerungskanal (EMS oder HTTP) aufrufen und ihm mitteilen, dass er einen anderen Prozess laden soll. Dies funktioniert zwar immer noch ein Hack wegen der eingeschränkten Funktionalität von Designer.

Wir haben uns auch Service Grid und BWSE angeschaut und das schien uns nichts mehr zu geben. Eigentlich ein bisschen begrenzender.

Es gibt ein altes Framework namens Raccoon , das über Tibco ActiveEnterprise gebaut wurde.

Es hat eine Komponente für Komponententests namens UiTest , die sich auf RendezVous Messaging konzentriert.

Es scheint jedoch in letzter Zeit nicht zu viel Aktivität zu haben.

Mit BW-TEST können Sie TDD üben und Ihre Projekte zu Ihrem CI hinzufügen Schau es dir auf Ссылка

Es ist Open Source

IBM RIT ist ein sehr gutes Tool, um an solchen Szenarien zu arbeiten, es kann Ihnen helfen, verschiedene Szenarien zu erstellen und auch die Codeabdeckung zu evaluieren.

Ich empfehle IBM RIT. Es ist Teil von IBM RTW Stack. Sie können es leicht in TDD und CI / CD-Modellen der Lieferung verwenden.