Инструменты тестирования Tibco Unit

Question

Кто-нибудь знает, какие инструменты модульного тестирования доступны при разработке процессов Tibco?

В ближайшие несколько месяцев я буду работать над проектом Tibco, и я пытаюсь найти какие-либо существующие рамки тестирования модулей, которые могли бы упростить работу с использованием подхода TDD.

До сих пор единственным, кого я смог найти, называется BWUnit. Кажется, это нормально, но в настоящее время он находится в стадии бета-тестирования и коммерческого программного обеспечения. Если возможно, я хотел бы использовать инструмент с открытым исходным кодом, но, пока он умеет делать хорошую работу, я был бы счастлив.

Знаете ли вы, что кто-нибудь знает какие-либо другие инструменты тестирования единиц для развития Tibco?

Также есть ли у кого-нибудь опыт работы с BWUnit? Насколько он полезен?

Answer 1

Для проектов BW я приготовил свою собственную модульную систему тестирования на основе самих процессов BW. Таким образом, автоматические тесты и проверки кодируются в самом проекте TIBCO.

Для проектов AMX я рекомендую SOAPUI для автоматического тестирования ваших услуг. Тем не менее, я закодировал все модульные тесты на базовом языке, в моем случае Java, используя JUnit. Классы реализации под компонентами ссылаются друг на друга непосредственно в модульных тестах, минуя код AMX, выполняющий обмен сообщениями.

Answer 2

Существует старый каркас под названием Raccoon, построенный над Tibco ActiveEnterprise.

Он имеет компонент для модульного тестирования под названием UiTest, ориентированный на обмен сообщениями RendezVous.

В последнее время, похоже, не слишком много активности.

Answer 3

У меня был большой успех, создавая слой интерфейса мыла для каждого из моих процессов (принимая те же аргументы) и используя SoapUI, чтобы выполнить все тесты, проведенные из нескольких таблиц базы данных.

Edit:

То, что я описал довольно много, как BWUnit работает: (., Может быть, с немного меньше ручной работы, но то же самое понятие) создает интерфейс веб-службы вокруг каждого из процессов

Test Input (SoapUI) -> Testable интерфейс (мыло/Эмс/и т.д.) -> Существующий процесс -> Выход Интерфейс -> assert (SoapUI)

Вы могли бы сделать тестирование в самой TIBCO, с файлами, RV, JMS или любой вход для этого матового er, за исключением того, что вы сами пишете весь код утверждения теста, а не используете существующий инструмент, в котором все это встроено. Затем вы можете полагаться на SoapUI, чтобы генерировать все ваши отчеты JUnit и т. д.

Если вы хотите получить действительно вы можете добавить цель soapui к сценарию сборки, чтобы включить модульные тесты и/или функциональные тесты для каждой сборки после ее развертывания.

Answer 4

Одобрено использование протокола (используется). Были упомянуты Racoon и SoapUI. С их помощью вы можете протестировать уровень «на модуль». Это тесты Component или System. Особенно полезно для тестов производительности. Однако это самый распространенный способ тестирования компонентов tibco.

Я посмотрю BWUnit, выглядит интересным и интегрированным с CI-серверами (я создал подобный инструмент в проекте). Недостатком этого подхода может быть то, что системы TIBCO обычно состоят из разных инструментов, а не только BW, это означает, что для общей системы используются компоненты Java, серверы C++ и т. Д.

Существует также коммерческий инструмент под названием GHTester (http://www.greenhatconsulting.com/ghtester/)

Если вы используете RV вы можете посмотреть на http://www.rvsnoop.org/ для захвата сообщения в replayable формате бесплатно (инструмент OSS, что я начал)

Answer 5

С BW-ТЕСТ вы можете практиковать TDD и добавить свои проекты на ваш CI Проверьте это на http://nicosommi.com/?p=209

Это открытый исходный код

Answer 6

Попытка сделать методологию как TDD с помощью мыла UI будет не очень эффективный. Я использовал это для BW, и вы не получаете такой же уровень детализации и комфорта из полного набора тестов. BWUnit - хороший инструмент, и если у вас хорошие отношения с ребятами из TIbco PSG, вы можете получить TibUnit, который является PSG Ware, как CLE.

Мы также разработали план использования внешней модульной тестовой среды, например .net, а затем используем шаблон контроллера для замены процессов с использованием флага переопределения динамического процесса. Так esentaially мы бы канал управления, что бы сказать что-то вроде

управления - процесс 1 Override -/Процессы/SomeProcess.process - Процесс 2 Override {Blank}

так в тестовом модуле вы могли бы в своей установке вызвать BW с помощью вашего канала управления (EMS или HTTP) и сказать ему загрузить другой процесс. В то время как это работает, его все еще взломать из-за ограниченной функциональности Дизайнера.

Мы также рассмотрели Service Grid и BWSE, и это, похоже, не дало нам больше. На самом деле немного более ограничивающим.

Answer 7

IBM RIT - очень хороший инструмент для работы над такими сценариями, он может помочь вам утвердить разные сценарии, а также оценить покрытие кода.

Answer 8

Я рекомендую IBM RIT. он является частью стека IBM RTW. Вы можете легко использовать его в моделях TDD и CI/CD.