Back when BizTalk Server 2009 was released, there was a lot of buzz about the new integrated support for unit testing of schemas, maps, and pipelines, and cleaner support for automated builds driven by Team Foundation Server (TFS). These were definitely welcome additions that made it much easier to enable continuous integration with automated build and testing. However, there were some things missing. In this article, I’ll review the current state of automated build and testing capabilities that exists for BizTalk Server 2010 when using Visual Studio 2010 Team Foundation Server (TFS). I will first examine the items lacking out of the box, and then direct you to community projects that can improve the situation.
When it comes to the built-in unit testing support in BizTalk Server 2009 and 2010, there are still some areas lacking. For example, testing schemas with imports yielded erroneous results, as all of the necessary schemas were not used in validation. Testing pipelines cannot be accomplished purely in memory with the API exposed. There was not really any work done to enable integration and functional testing of orchestrations. Finally, the automated build process did not take into account the necessity for the bits that were compiled to be deployed somewhere for testing -- possibly due to the lack of functional and integration testing support for orchestrations (i.e., there would be no reason to deploy bits that could not be tested anyway).
Thankfully, community efforts filled in most of these gaps for BizTalk Server 2009, and indeed in most cases these community projects preceded the implementation of automated build and testing support in BizTalk Server. Pipeline, pipeline component, and flat-file schema testing was made much more elegant with Tomas Restrepo’s PipelineTesting library. Functional and integration testing of orchestrations was provided for in BizUnit, and automated deployment in preparation for test could be enabled using the bLogical Custom Tasks.
You may have used one or all of these community tools when setting up an environment with BizTalk Server 2009 and Team Foundation Server 2008, and it is still possible to use most of the functionality offered by these in BizTalk Server 2010 and Team Foundation Server 2010. If you have not had any experience with enabling automated testing of BizTalk Server applications, you may benefit from our self-paced online training course covering BizTalk testing strategies.
PipelineTesting Library
The PipelineTesting library is a mature and stable library that has been well maintained and has always remained a step ahead of what was offered out of the box with each version of BizTalk Server. It not only provides a less-clunky API, but a fuller feature set. This is best shown by a short example (although this example does not even get into the depth of what is provided in the PipelineTesting library).
Here is some rough sample code that shows basic usage of the built-in BizTalk Pipeline Testing support:
[TestMethod]
public void TimeReportFFReceivePipeline_TimeReportFF_OutputValidates()
{
// Built-in BizTalk Pipeline Testing Support
// (CON: Must be enabled on pipeline project before compilation)
// CON: Must create the pipeline ahead of time
TimeReportFFReceivePipeline target = new TimeReportFFReceivePipeline();
// PRO: Can provide a list of input documents without loading them explicitly
// CON: Input documents must exist on disk
StringCollection inputDocuments = new StringCollection();
inputDocuments.Add(Path.Combine(TestContext.TestDeploymentDir, "TimeReport_3.txt"));
StringCollection parts = new StringCollection();
Dictionary schemas = new Dictionary();
// CON: Must reference .xsd file
schemas.Add("TestWorkshopApplication.Messaging.TimeReportFF", @"..\..\..\Messaging\TimeReportFF.xsd");
target.TestPipeline(inputDocuments, parts, schemas);
// CON: Must locate output messages as files
DirectoryInfo testDir = new DirectoryInfo(TestContext.TestDeploymentDir);
FileInfo[] outputList = testDir.GetFiles("*.out");
Assert.IsTrue((outputList.Length > 0), "No outputs for pipeline found");
foreach (FileInfo file in outputList)
{
/* Additional testing of message content */
}
}
Now compare that with a code performing roughly the same test using the PipelineTesting library:
[TestMethod]
public void TimeReportFFInPipeline_TimeReportFF_OutputValidates()
{
// PipelineTesting Library Pipeline Testing Support
String sourceFile = Path.Combine(TestContext.TestDeploymentDir, "TimeReport_4.txt");
// PRO: Can compose a pipeline at runtime
FFDisassembler ffDasm = Disassembler.FlatFile().WithDocumentSpec(typeof(TimeReportFF));
ReceivePipelineWrapper target = Pipelines.Receive().WithDisassembler(ffDasm);
target.AddDocSpec(typeof(TimeReportFF));
MessageCollection result;
// CON: Have to manually load input document
// PRO: Input document can exist only in memory
using (var readStream = File.OpenRead(sourceFile))
{
IBaseMessage msg = MessageHelper.CreateFromStream(readStream);
result = target.Execute(msg);
}
Assert.IsTrue(result.Count > 0, "No outputs found from flat file pipeline");
// PRO: Raw IBaseMessage instances of outputs are available in memory
foreach (IBaseMessage msg in result)
{
/* Additional testing of message content or context */
}
}
It actually doesn't take too much effort to get this library working with your BizTalk Server 2010 solutions, and in turn with Team Foundation Server 2010. You will have to upgrade the solution to the Visual Studio 2010 format, and re-reference the PipelineObjects library (exists under the \Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies folder). If you don't have NUnit installed, you can exclude the Test project from the build. Once you have it built, you're good to start writing tests against your BizTalk Server 2010 artifacts. When automating the build and test with Team Foundation Server, you will need to remember to include the .dll somewhere within source control.
BizUnit 3.1
BizUnit is a framework for performing automated integration and functional testing of BizTalk solutions. It takes a black-box approach, and requires that all artifacts are built and deployed before testing commences. If you already perform manual end-to-end testing of your BizTalk applications, you could likely benefit greatly from BizUnit over time. It provides a huge library of pre-built test steps (e.g., start BizTalk host, copy a file, wait for a file, execute a database query) that have the net effect of saving you a lot of time. Test cases, which are combinations of test steps, exist in a declarative XML format that are processed by the BizUnit class which can be invoked from within your MSTest or NUnit test assemblies.
Getting BizUnit working for BizTalk Server 2010 is not necessarily a very easy process. Before you even begin, you must consider that there are two versions currently available. The most recent version is BizUnit 4.0 Beta, which completely changes the test case format (to use XAML), and looks to be the way of the future. However, it does not look like that version has been updated in quite some time, so it is unclear when a final release will be ready. The other version available is BizUnit 3.1, which is stable and has a fully developed library of test steps along with full documentation. For the sake of this blog posting, we will go forward with 3.1, and examine some of the issues you will encounter.
This is another instance in which you will have to upgrade the solution to the Visual Studio 2010 solution file format. From there, you will notice that the solution has a project for each category of test step (e.g., BizTalk steps, LoadGen steps, MQ Series steps, Outlook automation steps, etc...). You can exclude the project for any type of step that you will not be using. Then for each of the “Steps” projects, you will need to re-reference assemblies, so that the latest versions are referenced. You might notice at this point, that the BizTalkSteps project has a dependency on the PipelineTesting library already discussed. You will definitely want to include the version that you built against the BizTalk Server 2010 binaries here. This is another place where you will need to remember to include the .dll's for both the BizUnit runtime and the steps that you will be using within source control, or simply install BizUnit on each build server if that makes more sense in your environment.
bLogical Custom Tasks
With BizTalk Server 2009, it became possible to automate builds of BizTalk applications without installing Visual Studio on the build server (though it is required to install the Project Build Component from the BizTalk installation media). It was also possible with BizTalk Server 2009 to automate tests and, with the help of community tools, automate integration and functional tests. However it was still not possible, using only out-of-the-box functionality, to include deployment as part of the build. The custom MSBuild Tasks for BizTalk by bLogical were developed to add the missing deployment step to the automated build process. Unfortunately, there are a few issues that still need to be overcome for these to work with Team Foundation Server 2010.
First, the easiest problem to deal with is in the GacHelper.cs class within the project:
namespace Blogical.Shared.Tools.BizTalkBuildTasks.Internal
{
public class GacHelper
{
#region Private Fields
const string ToolName = "bin\\gacutil.exe";
#endregion
This path gets concatenated with the path to the .NET Framework SDK to resolve the full path to the gacutil tool. Unfortunately, this will reference the old gacutil tool. For .NET 4 assemblies, the new tool path should be "bin\\NETFX 4.0 Tools\gacutil.exe".
The second hurdle isn't so easily solved. There is a dependency, mainly in the internal TeamBuildTask base class, on classes within the Microsoft.TeamFoundation.Build.Proxy namespace. This has been obsoleted, and no longer appears in the 2010 version of the assembly. This means that, at least for now, you will now have to provide your own solution for these small missing pieces in the automated build/deployment process. Post a comment if you have found an alternative solution, or keep watching this space for updates on this.
Summary
Using BizTalk Server 2010, you can still benefit from the automated build and testing capabilities released with BizTalk Server 2009, and most of the community solutions developed to enable continuous integration. There are a few steps necessary to get everything working and setup, and a few missing pieces that you will have to build yourself, but the end result is beautiful.
Also, bear in mind that Team Foundation Server is not just about source control and it's not just about automated build or testing. It's also about issue tracking, project management, and reporting. If you are paying for a license, make sure that your organization is taking full advantage of it -- especially on your BizTalk Server integration solutions. Be sure to check our new collection of instructor-led training on Application Lifecycle Management using Visual Studio 2010 and Team Foundation Server 2010.