Although BizUnit is widely used to test BizTalk solutions it could be very useful for the automated testing of different distributed systems. In this post I will try to have a look at this framework from generic integration developer point of view.
BizUnit is designed to enable a developer or a tester to rapidly build test cases which are simply XML documents (although it is possible to construct them dynamically using BizUnit object model as well). Each test case consists of three stages, test setup, test execution and test cleanup, the cleanup stage is always executed (even if the main execution stage fails). Each stage may consist of zero or more test steps, test steps are in general independent although state can be passed between them in the ‘context’ object by the framework.
BizUnit is a framework which doesn’t require to work with any particular unit test engine, it works equally well with NUnit and VS Unit Testing, though you could write your own code to do the same.
The diagram below illustrates the format of a test case.
In addition to test steps, BizUnit has so called validation steps and context loader steps. These are essentially sub-steps and can in general be independently executed inside any test step. A test step within a test case can be marked with the attribute - runConcurrently which causes subsequent test steps to be started before it has completed. In addition test steps maybe marked with the attribute - failOnError, setting it to false cause BizUnit to ignore a failure of that test step, this is additional flexibility when you want to go further through test scenario despite of any failure in this marked test step.
Test Steps
A test step is a .NET class which implements the
ITestStep interface:
public interface ITestStep
{
void Execute(XmlNode testConfig, Context context);
}
BizUnit will create and execute the test steps as dictated by the Xml test case. The test case will list the steps that need to be executed in each stage of the test. The example below will cause BizUnit to create the
BizUnit.FileCreateStep. BizUnit uses the
assemblyPath and
typeName to load and create the type:
<TestStep assemblyPath="" typeName="BizUnit.FileCreateStep, BizUnit,
Version=3.0.0.0, Culture=neutral, PublicKeyToken=8ab3cc29608bfce0">
...
</TestStep>
Validation Steps
BizUnit supports validation steps which may be nested within test steps which support validation. This means that an file read step may use an XML validation step or a regular expression validation step to validate the data that it receives. Validation steps need to implement the
IValidationStep interface.
public interface IValidationStep
{
void ExecuteValidation(Stream data, XmlNode validatorConfig, Context context);
}
The test step snippet below illustrates how a validation step is embedded in a
file read step (typeName property shortened):
<TestStep assemblyPath="" typeName="BizUnit.FileValidateStep">
...
<ValidationStep assemblyPath="" typeName="BizUnit.XmlValidationStep">
<XmlSchemaPath>..\Data\Order.xsd</XmlSchemaPath>
<XmlSchemaNameSpace>http://X.Order</XmlSchemaNameSpace>
<XPathList>
<XPathValidation query=
"/*[local-name()='Order' and namespace-uri()='http://X.Order']
/*[local-name()='ID' and namespace-uri()='']">235</XPathValidation>
</XPathList>
</ValidationStep>
</TestStep>
Context Loader Steps
Similarly, BizUnit supports context loader steps, which are responsible for loading data into the BizUnit context. These steps need to implement the
IContextLoaderStep interface as shown below:
public interface IContextLoaderStep
{
void ExecuteContextLoader(Stream data, XmlNode contextConfig, Context context);
}
Precooked tests
Here’s a list of non-BizTalk specific test steps in BizUnit build 3.0.0.0, the documentation provides more details around what these steps do and how to use them but their names can give an idea what they do anyway:
BAMDeploymentStep CheckPop3MailStep ContextManipulatorStep
DatabaseDeleteStep DBExecuteNonQueryStep DBQueryReturnXmlStep DatabaseRowCountStep DBQueryStep ExportDBDataToDataSetStep ImportDatasetToDBStep
DelayStep DotNetObjectInvokerStep ExecuteCommandStep
EventLogCheckStep EventLogClearStep EventLogSaveStep
FileCreateStep FileDeleteMultipleStep FileDeleteStep FileMoveStep FileMultiValidateStep FilesExistStep FilesMoveStep FileValidateStep RenameDirectoryStep WaitOnFileStep
HttpPostStep HttpRequestResponseStep SOAPHTTPRequestResponseStep
MSMQCreateQueueStep MSMQDeleteQueueStep MSMQQueuePurgeStep MSMQReadStep MSMQWriteStep
MQSeriesClearQueueStep MQSeriesGetStep MQSeriesPutStep
PerfMonCounterMonitorStep PerfmonCountersStep
RuleEngineStep SMTPReadStep OutlookReadStep
ExcelTestStep LoadGenExecuteStep
Validation Steps:
BinaryValidationStep CodeValidationStep ContextValidationStep RegExValidationStep XmlValidationStep XmlValidationStepEx
Context Loader Steps:
RegExContextLoader TextContextLoader XmlContextLoader
You can see that there are steps for working with databases, file system, .NET objects, performance counters, event log. You can use Http, SOAP, SMTP, MSMQ, MQSeries, BAM, RuleEngine capabilities to execute your testing. There is a very interesting possibility to automate Web applications testing using LoadGen (LoadGenExecuteStep). You can also compose a scenario for testing inside a spreadsheet, doing it for different environments, e.g. test, staging and production environments, saving all information about them in the spreadsheet and using Excel test case runner (ExcelTestStep) for test launching. I have included in this list such steps as BAMDeploymentStep and RuleEngineStep because they are no longer only BizTalk-connected technologies, you could utilize them from any .NET application and so you could consider them from more generic point of view.
Although BizUnit core has many ready generic steps sometimes you have a situation when it is not enough. Actually there are two possibilities now: have a look at BizUnitExtensions Test Libraries or you could simply add a new test into framework creating a new class implemented ITestStep interface and recompiling the core.
What is BizUnitExtensions?
In this community
project you can find some enhancements/extensions to the steps in the base libraries (the enhancements being packaged in separate assemblies) , new steps, support applications, tutorials and other documentation to help you understand and use it. This is the set of libraries which can be interested for us:
- BizUnitExtensions - General Steps such as DotNetObjectInvokerEx, SoapHttpRequestResponseEx, XmlPokeStep etc.
- BizUnitExtensions.EntLib - EntLib based DBQueryStep, DatabaseDeleteStep etc
- BizUnitExtensions.Oracle - OracleDBQueryStep.
Along with obvious benefit of additional test steps for working with Oracle and Microsoft Enterprise Library there are some new interesting test steps there, for example, XmlPokeStep, which enables a developer to construct test cases dependent on results of previously run test cases.
BizUnit Designer
When you compose your scenario for BizUnit testing you usually work in XML editor (standalone or VS Studio built-in) and add your tests simply adding <TestStep>…</TestStep> tags with their appropriate attributes and sub-elements. So you need to know syntax of those elements well enough. For those who doesn’t want to waste time for learning this stuff BizUnit Designer could be recommended. Actually it is a GUI that allows rapid creation of BizUnit test cases. The easy to use drag and drop user interface has minimal learning curve which will get you up and running with test cases in a matter of minutes.
A piece of warning: tests generated by current version of BizUnit Designer are not compatible yet with newest version of BizUnit 3.x. I hope it will be corrected soon. Here you can see how this designer looks like.
BooUnit
There is another interesting community project BooUnit which hides BizUnit XML format behind a DSL written using boo language to simplify generation of BizUnit test cases. The intention was the same as in BizUnit Designer project to get rid off writing tests and managing them manually. But the result is arguable from my point of view because instead of writing XML test you should now write and know DSL syntax although there are some new interesting features to use there. For example, you could add custom logic and computations directly in the test instead of simply invoking a sequence of BizUnit steps, you don’t need to compile BooUnit tests because they are directly executable.
Conclusion
BizUnit test framework is very flexible and extensible framework which can be used for automated unit, functional and integration testing of different distributed systems. Test cases can be rapidly built as generic reusable XML documents and can be auto-generated then. A number of drivers can drive BizUnit: custom .NET code, NUnit or Visual Studio 2005 Unit Testing. BizUnit in combination with MSBuild, NUnit and CruiseControl.NET fits very well into continuous integration process of software development and as such could be highly recommended.