Tibco herramientas de prueba de la unidad [cerrada]

Question

¿Alguien sabe qué unidad de herramientas de prueba están disponibles en el desarrollo de procesos Tibco?

En los próximos meses voy a estar trabajando en un proyecto de Tibco y estoy tratando de encontrar cualquier unidad existente pruebas de marcos que pueden hacer el trabajo más fácil de construir con un enfoque TDD.

Hasta el momento, el único que he sido capaz de localizar se llama BWUnit . Parece bien, pero su actualmente en fase beta y su software comercial. Si es posible me gustaría utilizar una herramienta de código abierto, pero el tiempo que es capaz de hacer un trabajo bueno sería feliz.

Así que ¿alguien sabe de cualquier otra unidad de herramientas de pruebas para el desarrollo de Tibco?

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

Answer 1

Para proyectos BW, cocinaba mi propio marco de pruebas unitarias basado en BW Procesos sí. Así las pruebas y validaciones automatizadas se codifican en el proyecto TIBCO sí mismo.

Para los proyectos de AMX recomiendo SOAPUI pruebas automatizadas de sus servicios. Sin embargo, codifiqué todas las pruebas unitarias en el lenguaje subyacente, en mi caso de Java, utilizando JUnit. Las clases de implementación en virtud de los componentes de referencia entre sí directamente en las pruebas de unidad, sin pasar por el código AMX haciendo la mensajería.

Answer 2

He tenido gran éxito la creación de una capa de interfaz de jabón para cada uno de mis procesos (que toman en los mismos argumentos) y apalancamiento SoapUI hacer todas las pruebas impulsado desde unas pocas tablas de bases de datos.

Editar:

Lo que he descrito es más o menos cómo está funcionando BWUnit: (. 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) -> Interfaz comprobable (jabón / EMS / etc) -> proceso existente -> salir de la interfaz -> Las afirmaciones (SoapUI)

Se puede hacer la prueba dentro de TIBCO sí, con los archivos, RV, JMS, o cualquier entrada para el caso, a menos que usted está escribiendo todo el código afirmación de prueba a sí mismo en lugar de utilizar una herramienta existente que lo tiene todo incorporado. a continuación, puede depender de SoapUI para generar todos los informes JUnit etc.

Si desea obtener realmente de lujo, se puede añadir un objetivo soapUI a su script de generación para incluir las pruebas unitarias y / o pruebas funcionales para cada generación una vez que se desplegó.

Answer 3

Deopends sobre el protocolo utilizado (lo que se utiliza). Mapache y SoapUI se ha mencionado. Con ellos se puede probar en un nivel "por módulo". Es decir pruebas componente o sistema. Especialmente usful para las pruebas de rendimiento. Sin embargo, esta es la forma más común de componentes TIBCO prueba.

Me va a echar un vistazo a la BWUnit, parece interesante e integrado con servidores de CI (He construido una herramienta similar en un proyecto). Un defecto de este approch puede ser que los sistemas de TIBCO por lo general se componen de diferentes herramientas y no sólo BW, significa esto que los componentes de Java, C ++ servidores y tan fuerte se utiliza para para el sistema total.

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

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

Answer 4

Tratar de hacer una metodología como TDD usando la interfaz de usuario de jabón no sería muy eficaz. He utilizado este para PN y usted no recibe el mismo nivel de granularidad y la comodidad de un conjunto de pruebas de unidad completa. BWUnit es una herramienta buena, y si usted tiene una buena relación con los chicos TIBCO PSG puede ser capaz de obtener TibUnit que es una Ware PSG como CLE.

También he llegado con un plan para utilizar un marco externo Unidad de prueba como .net y luego usar un patrón de controlador que cambiar los procesos que utilizan la bandera de anulación proceso dinámico. Así esentaially que tendríamos un canal de control que decir algo como

Control    - Proceso 1 Anulación              - / Procesos / SomeProcess.process    - Proceso 2 Anulación              {Blanco}

por lo que en su prueba de unidad que sería capaz en su configuración para llamar BW utilizando su canal de control (EMS o HTTP) y decirle que cargue un proceso diferente. Aunque esto funciona su todavía un corte debido a la limitada funcionalidad del diseñador.

También hemos mirado Grid Service y BWSE y que no apareció para darnos algo más. En realidad un poco más limitante.

Answer 5

Hay un marco de edad llamado mapache construido sobre Tibco ActiveEnterprise.

Tiene un componente de la unidad de pruebas llamada UiTest centrado en la mensajería de encuentro.

No parecen tener demasiada actividad últimamente, sin embargo.

Answer 6

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 7

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

Answer 8

Recomiendo IBM RIT. que es parte de la pila de IBM RTW. Se puede utilizar en los modelos de TDD y CI / CD de la entrega fácilmente.