Для проектов BW я создал свою собственную среду модульного тестирования, основанную на самих процессах BW. Таким образом, автоматизированные тесты и проверки закодированы в самом проекте TIBCO.
Для проектов AMX я рекомендую SOAPUI для автоматического тестирования ваших сервисов. Однако я закодировал все модульные тесты на основном языке, в моем случае Java, с помощью JUnit. Классы реализации в компонентах ссылаются друг на друга непосредственно в модульных тестах, минуя код AMX, выполняющий обмен сообщениями.
Есть старый фреймворк под названием Raccoon , построенный на основе Tibco ActiveEnterprise.
В нем есть компонент для модульного тестирования под названием UiTest , ориентированный на обмен сообщениями RendezVous.
Хотя, похоже, в последнее время он не слишком активен.
Мне очень удалось создать слой интерфейса мыла для каждого из моих процессов (принимая одни и те же аргументы) и использовать SoapUI для выполнения всего тестирования, основанного на нескольких таблицах базы данных.
Изменить:
То, что я описал, в значительной степени похоже на то, как работает BWUnit: он создает интерфейс веб-службы для каждого из ваших процессов (возможно, с меньшим объемом ручной работы, но с той же концепцией).
Тестовый ввод ( SoapUI) -> Тестируемый интерфейс (soap / ems / etc) -> Существующий процесс -> Интерфейс выхода -> Утверждения (SoapUI)
Вы можете проводить тестирование внутри самого tibco, с файлами, RV, JMS или любыми входными данными для это важно, за исключением того, что вы сами пишете весь тестовый код утверждения, а не используете существующий инструмент, в котором все это встроено. Затем вы можете положиться на SoapUI для генерации всех ваших отчетов JUnit и т. д.
Если вы действительно хотите получить Замечательно, вы можете добавить цель soapui в свой сценарий сборки, чтобы включить модульные и / или функциональные тесты для каждой сборки после ее развертывания.
Зависит от используемого протокола (что используется). Были упомянуты Racoon и SoapUI. С ними вы можете тестировать на уровне «по модулю». Это компонентные или системные тесты. Особенно полезно для тестов производительности. Однако это наиболее распространенный способ тестирования компонентов tibco.
Я посмотрю на BWUnit, выглядит интересно и интегрировано с CI-серверами (я создал аналогичный инструмент в одном проекте). Недостатком этого подхода может быть то, что системы TIBCO обычно состоят из различных инструментов, а не только BW, это означает, что компоненты Java, серверы C ++ и т. Д. Используются для всей системы.
Существует также коммерческий инструмент под названием GHTester ( http://www.greenhatconsulting.com/ghtester/ )
Если вы используете RV, вы можете взглянуть на http: //www.rvsnoop.org/ для бесплатного захвата сообщений в воспроизводимом формате (инструмент OSS, который я запустил)