Tibco Unit Testing tools

Question

¿Alguien sabe qué herramientas de pruebas unitarias están disponibles para desarrollar procesos Tibco?

En los próximos meses estaré trabajando en un proyecto de Tibco y estoy tratando de encontrar cualquier marco de prueba de unidades existente que pueda facilitar el trabajo de construir con un enfoque TDD.

Hasta ahora, el único que he podido localizar se llama BWUnit. Parece correcto, pero actualmente está en beta y su software comercial. Si es posible, me gustaría usar una herramienta de código abierto, pero siempre que sea capaz de hacer un buen trabajo, estaría contento.

¿Alguien sabe de alguna otra herramienta de prueba para el desarrollo de Tibco?

Además, ¿alguien tiene alguna experiencia con BWUnit? ¿Qué tan útil es/was it?

Answer 1

Para proyectos de BW, cociné mi propio marco de Prueba de Unidad basado en los Procesos de BW. Entonces, las pruebas y validaciones automáticas están codificadas en el proyecto TIBCO.

Para proyectos de AMX, recomiendo SOAPUI para la prueba automatizada de sus servicios. Sin embargo, codifiqué todas las pruebas unitarias en el lenguaje subyacente, en mi caso Java, usando JUnit. Las clases de Implementación bajo los componentes se referencian entre sí directamente en las pruebas unitarias, eludiendo el código AMX que hace los mensajes.

Answer 2

Hay un antiguo framework llamado Raccoon construido sobre Tibco ActiveEnterprise.

Tiene un componente para pruebas unitarias llamado UiTest centrado en la mensajería RendezVous.

No parece que haya mucha actividad últimamente, sin embargo.

Answer 3

He tenido un gran éxito creando una capa de interfaz de jabón para cada uno de mis procesos (teniendo en los mismos argumentos) y aprovechando SoapUI para hacer todas las pruebas dirigidas desde unas pocas tablas de base de datos.

Editar:

Lo que he descrito es más o menos como BWUnit está trabajando: (. Tal vez con un poco menos trabajo manual, pero el mismo concepto) que crea una interfaz de servicios web en torno a cada uno de sus procesos

Test de entrada (soapUI) -> comprobable interfaz (jabón/eMS/etc) -> proceso existente -> salir de la interfaz -> las afirmaciones (soapUI)

que podría hacer la prueba dentro de TIBCO sí, con los archivos, RV, JMS o cualquier entrada para ese mate er, excepto que está escribiendo todo el código de aserción de prueba usted mismo en lugar de usar una herramienta existente que lo tiene todo integrado. Luego puede confiar en SoapUI para generar todos sus informes JUnit, etc.

Si desea obtener realmente sofisticado, puede agregar un objetivo Soapui a su script de compilación para incluir las pruebas unitarias y/o las pruebas funcionales para cada compilación una vez que se implemente.

Answer 4

Depende del protocolo utilizado (lo que se utiliza). Racoon y SoapUI han sido mencionados. Con ellos puede probar en un nivel "por módulo". Eso es pruebas de Componente o Sistema. Especialmente útil para las pruebas de rendimiento. Sin embargo, esta es la forma más común de probar los componentes de tibco.

Echaré un vistazo a la BWUnit, se ve interesante e integrada con los servidores CI (he creado una herramienta similar en un proyecto). Una falla de este enfoque puede ser que los sistemas TIBCO usualmente están compuestos por diferentes herramientas y no solo BW, esto significa que los componentes de Java, los servidores C++ y fort se usan para todo el sistema.

También hay una herramienta comercial llamada GHTester (http://www.greenhatconsulting.com/ghtester/)

Si está utilizando RV es posible echar un vistazo a http://www.rvsnoop.org/ para capturar los mensajes en un formato de volver a jugar de forma gratuita (herramienta de software libre que empecé)

Answer 5

Con BW-TEST se puede practicar TDD y añadir sus proyectos a su CI Compruébelo usted mismo en http://nicosommi.com/?p=209

Es de código abierto

Answer 6

Tratar de hacer una metodología como TDD usando la interfaz de usuario de jabón no sería muy eficaz. He usado esto para BW y no obtiene el mismo nivel de granularidad y comodidad de un conjunto de pruebas de unidades completas. BWUnit es una buena herramienta, y si tienes una buena relación con tus chicos de TIbco PSG, es posible que puedas obtener TibUnit, que es un PSG Ware como CLE.

También hemos ideado un plan para utilizar un marco de prueba de unidad externo como .net y luego utilizamos un patrón de controlador para intercambiar los procesos utilizando el indicador de anulación de proceso dinámico. Así esentaially que tendríamos un canal de control que decir algo como

control - 1 Proceso de anulación -/Procesos/SomeProcess.process - Proceso 2 Anulación {blanco}

por lo que en su unidad de prueba usted podría en su configuración llamar a BW usando su canal de control (EMS o HTTP) y decirle que cargue un proceso diferente. Si bien esto funciona, sigue siendo un truco debido a la funcionalidad limitada de Designer.

También hemos consultado Service Grid y BWSE y eso no parece darnos nada más. En realidad un poco más limitante.

Answer 7

IBM RIT es una herramienta muy buena para trabajar en este tipo de escenarios, puede ayudarle a afirmar diferentes escenarios y también para evaluar la cobertura del código.

Answer 8

Recomiendo IBM RIT. es parte de la pila de IBM RTW. Puede usarlo fácilmente en modelos de entrega TDD y CI/CD.