Пока BizUnit используется программистами, их не смущает ни тот факт, что TestSteps для этого framework должны быть написаны на XML, ни тот, что для их запуска нужно откомпилироварь т.наз. boilerplate code. Тем более программисту не может помещать дюжина параметров при создании таких TestStep как WebService Invoke : SOAP-Action, WS Namespace etc. - естественно ожидать от программиста, что составление таких сценариев не составит для него большого труда.
С другой стороны, когда BizUnit пытаются использовать как средство QA, эти же свойства framework становятся непреодолимой преградой для тех, кто не знаком с кодированием. Даже если прилежный сотрудник QA освоит XML-формат сценариев, то уж компилировать boilerplate code ему просто не на чем : не устанавливать же VS на каждой машине QA.
Может быть поэтому, а может быть в силу разделения труда между производством (программированием) и техническим контролем (QA), BizUnit применяется только программистами, да и то так, как бог на душу положит. Методические проверки ведь все равно остаются за QA; например, code coverage это разве не методология?
В общем, картина довольно грустная : BizUnit сам по себе и QA сам по себе.
Прежде чем пытать решить эту проблему, неплохо было бы посмотреть по сторонам с тем, чтобы узнать, кого еще она беспокоит и кто уже пробовал думать иначе, чем Kevin B Smith. Начать с того, что некоторые пытались просто облегчить процесс создания TestSteps, генерируя их XML из UI. К сожалению, автор BizUnit не предусмотрел настоящей metadata для steps, поэтому, BizUnit Designer, например, вынужден довольствоваться "документацией" (я все-таки надеюсь, что под "документацией" они имеют в виду комментарии в коде самого BizUnit).
booUnit пошел значительно дальше, но во-первых сам boo знаком исключительно энтузиастам и писать скрипты на нем, возможно, и легче, чем вникать в XML-формат BizUnit, но я не представляю, чтобы кто-то взялся изучать новый язык программирования только для того, чтобы изложить на нем пару десятков тестов для BizTalk.
Собственно на этом обзор рынка и заканчивается, оставляя впечатление, что либо BizUnit не принимают всерьез, либо наоборот - настолько принимают, что боятся слово поперек сказать.
Начнем с сериализации. Даже если реализовать Step-классы с необходимыми properties для XML-сериализации, это не избавит от необходимости в исполнении boilerplate-code, а только разломает существующий BizUnit framework. Представляется, что это слишком догорая цена для возможности автоматической генерации test cases. Поэтому просится сериализовать Step-классы с необходимо добавленными properties в XAML.
Что это даст? После сериализации полученный XAML можно скомпилировать в полноценный assembly, и если добавить к откомпилированным классам и методам атрибуты NUnit (TestFixture к классам и Test к методам),- получится загружаемый в NUnit модуль. Мало того, если откомпилировать сериализованный XAML в исполняемый assembly, не понадобится и NUnit. Очевидным недостатком такого подхода является то, что нужно по сути выбросить всю существующую реализацию BizUnit и переписать под XAML все уже созданные для него Step-классы. Наградой за приложенные усилия будет возможность создавать тесты автоматически, без какого-либо участия программиста в написании кода для теста. Другими словами, XAML позволит превратить BizUnit в настоящий инструмент QA.
Итак, попробуем. Сериализация в XAML не представляет особых трудностей, поэтому не стоит на ней останавливаться, займемся компиляцией XAML.