Каждый программист, более-менее ценящий свое время и нервы, знает, как славно работать в проекте, где всё покрыто тестами. О тестировании говорят везде, даже при собеседовании на работу теперь можно нарваться на вопрос «А как будете тестировать?». Более того, просидев ночь в отладке, до самого себя как-то легко и непринужденно открываешь, что пара-тройка тестов могли бы спасти начинающего стартапера, не говоря уже о суровых парнях из жестокого энтерпрайза. Правда, почему-то тестирование BizTalk приложений не пользуется популярностью, хотя я уверен, если уж и что-то нужно тестировать, то это точно средства интеграции.

Тестирование в BizTalk

Что можно тестировать в BizTalk решении «из коробки»? Собственно, вот список:

• Схемы
• Карты
• Пайплайны

Эти три компонента получили наибольшее внимание от Microsoft — возможность тестирования встроена в Visual Studio, а также достаточно хорошо задокументирована на MSDN: Unit Testing with BizTalk Server Projects.

Всё бы хорошо, но есть одно «но». Самая большая сложность в средствах интеграции состоит в том, чтобы правильно связать все компоненты между собой. И тут почему-то Microsoft не сделала практически ничего для тестирования — оркестровки, «сердце» бизнес-процесса, тестировать «из коробки» нельзя. И тут у начинающего бизтолкера начинает где-то внутри начинает грызть червячок сомнения, а правильный ли тулсет, технологию и компанию он выбрал? Одно дело, когда у тебя 3 оркестровки в домашней песочнице, а другое — когда приходится обеспечивать целостность процесса в рамках проекта интеграции штук эдак 5 разных сервисов (я не говорю уже о более запущенных случаях из практик банковского ПО). В таком свете, определенно, тестирование именно оркестровок выглядит наиболее желанным.

Как можно тестировать оркестровки?

Разумеется, раз Microsoft оставила всех программистов бизтолка вариться в собственном соку, эти самые программисты начали изощряться, все по-разному. Кто-то на форумах упражняется в скабрезных высказываниях, кто-то пилит свой фреймворк (но тоже не забывает про ругательства). К сожалению, мой коммитмент под проекты бизтолка не настолько сильный, чтобы садиться и браться за написание фреймворка, тем более в условиях ограниченного времени. Поэтому в свое время я потратил изрядное время на поиск более-менее работающих вариантов. И с результатами поисков вас сейчас бесплатно ознакомлю (а некоторым компаниям не повезло, и я успел срубить немного денег на проведении у них платных тренингов). Итак, как тестируемся:

• Ручные тесты (ну а что, monkey job всегда в почете у неленивых)
• Интеграционные тесты (попробуйте договориться на интеграционном проекте с участием хотя бы пяти компаниях об общем формате и времени проведения тестирований)
• Фреймворки

Поскольку первые два пункта суть есть несерьёзно, долго и не входит в рамки модных веяний Continuous Integration, глянем на фреймворки. Два года назад, когда я еще работал на проектах с бизтолком, мне были известны следующие:

—   BizUnit

• Последнее обновление в 2008г.

—   BizUnit 4.0

• Сложное конфигурирование и последнее обновление в 2011г.

—   BizMonade

• Пацаны изобрели BizTalk заново
• Неполная поддержка BizTalk 2010 (проблемы с генерацией)

—   BizMock

• Использование mock-адаптеров.

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

BizUnit

BizMonade

BizMock

На мой взгляд самым правильным тестированием является тестирование через BizMock. Потому что по сути парни встроили свои адаптеры в стандартный бизтолк, не меняя, как в BizMonade, движка и не требуя, как в BizUnit, каких-то совершенно непонятных конфигураций. Даже по виду смотришь на код тестов с использованием BizMock и чувствуешь, как тебя за пазуху положили и молока с печеньками дали.

BizMock

Пацаны, которые сделали BizMock, — вообще ребята ©. Очень хорошо получилось. Они сделали так, что ваше SUT (system under test) запускается в самом бизтолке, а идея, весь цимес в том, что они заменяют адаптеры (порты), которые используются вашим приложением, на свои фейки.

Я надеюсь, что читающий эти строки, во-первых, искренне мне благодарен за то, что я делюсь с миром своими наработками, а во-вторых, знает, что такое Moq (или Rhino Mocks) и вообще знаком с такими понятиями как mock \ fake object, shim, и, в-третьих, знаком хотя бы поверхностно с Т4, этой системой генерации всего по шаблону. Потому что все эти скиллы потребуются уже с заглавной страницы http://bizmock.codeplex.com:

BizMock is a framework for testing BizTalk Solutions using Visual Studio C# Test Projects.

With BizMock you can quickly test your Orchestrations, Schemas, Maps and Pipelines by writing unit tests that can emulate the messages received at receive ports and validate messages sent from send ports.

You start by declaring your solution artifacts in a xml file (orchestrations, ports, maps, message instances, message verifiers etc. ) a T4 template then generates .net types, that you can use in your tests.

For example:

—   with an orchestration artifact you have static type that allows to start your orchestration automatically (ports configured automatically with the BizMock Adapter ).

—   with a message artifact you can modify your message instance body and context properties at runtime ( by setting message properties )

—   with a message verifier artifact you can set expectations on messages sent by biztalk ports.

—   with a database artifact you can verify a row as been inserted in your custom Database.

A event artifact you can verify a specific event as been writed to the event log

BizMock supports : multipart messages, promoted properties, dynamic ports, direct binding and more; take a look at the samples.

2 releases are available: for Visual Stuido & BizTalk 2009 and for Visual Studio 2010 and BizTalk 2010

to get started go to http://bizmock.codeplex.com/documentation

Приступим. Скачиваем, устанавливаем, регистрируем адаптеры в BizTalk (через BizTalk Administration Console). Затем скачиваем тестовый проект и начинаем изучать.

Основные элементы BizTalk

—   Компоненты мокирования в BizTalk Server (адаптер)

—   Файлы artifacts.xml и artifacts.tt

—   Классы Artifacts (название настраивается), Expect, Submit.

Артефакты – это то, что есть в вашей системе, в вашем конкретном проекте.

Что есть артефакт на картинках выше? Это наши объекты – типы сообщений, порты, оркестровки. На их основе через Т4 будут сгенерированы классы, которые будут использоваться при написании тестов. Прошу заметить, что эти сгенерированные классы никак не замещают наши оригинальные элементы оркестровки, они лишь используются тестовым фреймворком для доступа к оным.

Пример

Разберем небольшой пример. Допустим, у нас есть небольшая система, которая работает по такой схеме:

Что-то куда-то отправляет и получает. Соответствующая оркестровка будет выглядеть примерно так:

И тут мы начнем тестировать. Поскольку C# язык не функциональный, тесты легко пишутся, и в случаях, когда они были написаны не по принципу what was hard to write should be hard to read, легко читаются. В императивном таком стиле. Примечание: в последнем выражении у меня используется FluentAssertions. Пишем и смотрим на оркестровку.

Приложение разворачивается в BizTalk, и тест запускается. Что делает тест? Он подставляет свои адаптеры вместо всяких других настоящих (ftp, webservice и прочее) и позволяет проверять, что же наша оркестровка отправляла. Также можно контролировать, что оркестровка получает. И в итоге проверять, верно ли работают все части оркестровки вместе.

Выводы

Получается, честное слово, довольно неплохо. Единственная трудность в том, чтобы научиться грамотно описывать всё в xml с артефактами, чтобы затем по T4 сгенерировались правильные объекты. Я рекомендую потратить на освоение этого фреймворка 1-2 дня и затем писать тесты именно с помощью него, поскольку этот фреймворк видится мне одним из самых «честных» способов протестировать оркестровки. Правда, есть одно “но” и с этим фреймворком — когда я тестировал свои проекты с его помощью, почему-то тестирование проходило успешно через раз. То есть раз запускаешь — работает, второй — не, третий — снова всё ОК. Поковырявшись немного в исходниках, я решил забить на поиски причины, поскольку время было сильно ограничено, и такое небольшое ограничение можно было пережить. Но я уверен, что, потратив неделю, можно докопаться до всех причин такого некорректного поведения. А может это и вовсе был какой-то глюк на той среде.