Unittesting вызываемые оркестровки

Question

Работая с BizTalk, мне нравится использовать вызываемые оркестровки (без конвейеров) как сервис для других оркестровок, предоставляя большую гибкость в архитектуре. Но юнит-тестирование их довольно коварно. Теперь я использую отдельное приложение с оркестровкой оболочки (просто вызывая оркестровку для тестирования), которую развертываю в BizTalk перед тестированием модуля.

Есть ли у кого-нибудь лучший способ для тестирования вызываемых оркестровок? Наиболее предпочтительно, чтобы у меня был юнит-тест, где мне не нужны никакие дополнительные артефакты для развертывания.

Заранее спасибо.

Answer 1

Трудно ответить на открытый вопрос с НЕТ, но я бы ответил, что это практически невозможно.

Оркестровки действительно тесно связаны с механизмом оркестровки BizTalk. Если вы хотите выполнить юнит-тестирование оркестровки, вам нужно будет смоделировать этот механизм оркестровки. Это нелегкая работа. Там есть много особенностей, о которых вам нужно подумать, таких как обезвоживание, сериализация, области действия, как на самом деле работает обмен сообщениями с вашей оркестровкой и т. Д. И т. Д.

Я бы сказал, что вы делаете правильные шаги, отделяя части своих оркестровок, а не привязывая их напрямую к физическим портам. Это делает тестирование возможным / более легким. Меньшее количество подключений также означает меньшее количество ошибок.

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

Если вы можете проверить свою оркестровку быстро и без особых усилий, просто развернув ее, отбросив сообщение и просмотрев результаты, то вы уже проводите больше испытаний, чем целый набор разработчиков BizTalk. Если вы упростите этот процесс и автоматизируете его там, где сможете (разверните, удалите файл, проверьте ожидаемый результат), вы по крайней мере упростите обнаружение регрессий.

Цель состоит в том, чтобы сделать тестирование таким простым, дешевым и надежным, чтобы его было проще тестировать, чем не тестировать. Таким образом вы не позволите менеджерам говорить skip the tests, they take too long, Вы хотите, чтобы они спрашивали: can you test it first?