Warning: This post is about a beta product. Details
might change before final release.

The beta of BizTalk Server 2009 brings a welcome new feature: Some basic support for
Unit Testing BizTalk artifacts; specifically for Pipelines, Maps and Schemas.

You can read the basics about how the new feature works in the product
documentation
; there’s not too much yet, but it’s enough to get a good idea of
how you use it.

I’d like to now share a few thoughts on this feature. Note: This is just my personal
opinion from playing with the API for a bit.

The Good

The first really good part about this feature is the fact that it even exists at all.
Facilities for creating and automating tests of BizTalk artifacts has been a sorely
lacking area of the product.

While Visual Studio had the Test option for maps and schemas since BizTalk 2004, and
it was sort of useful, it required way too much manual intervention and there was
no way to decently drive it through automation, making it useless for either unit
or regression testing.

The second thing I like about the unit testing feature is that, in it’s current incarnation,
it’s not intrinsically tied to MSTest (i.e. the Visual Studio Team System stuff).
This means you can use it with NUnit, xUnit, or your favorite testing tool.

The third interesting thing about the API is that it is a very simple API. In most
cases it really consists of just a single method call. Here’s an example of testing
a schema:

string fin = @"c:\temp\test1_in.xml";
Schema1 schema = new Schema1();
Assert.IsTrue(schema.ValidateInstance(fin, OutputInstanceType.XML));

The Not-so-Good

Not everything is rosy in BizTalk-land. Personally, I was somewhat underwhelmed by
the implementation of the Unit Testing features available in beta 1; particularly
since some of it could be addressed with fairly minor adjustments.

API Issues

Let’s start with the API: I mentioned before that the new testing API was simple.
However, it’s actually too simple. For example, consider the small test for
a schema I presented above: You simply create an input file to test with, call ValidateInstance() and
check the result. Great, no?

Well, if the test succeeds, then yes, it’s just fine. If it fails, however, because
the input file does not pass validation, then, it turns out, it’s missing one extremely
important functionality: There’s no way to get any details about why the
schema validation failed [1].

This means that diagnosing a failed test involves, at the very least, changing your
project settings in VS to use the failed input file as input to the schema in VS,
use the Validate Instance option in the IDE and examine the results in the output
window, where fortunately you do get more detailed error information.

This is extremely sub-optimal and requires way too much manual work. Can you imagine
if a change in a schema broke tens of tests and having to do this for each and every
single one of those? Ouch!

Another place where I feel the current API is not as nice as it could be is that it’s
strictly file-based. That is, you need to create actual files on disk to represent
inputs to the tests and store the resulting outputs. This is somewhat convenient for
many scenarios, and matches the existing functionality in BizTalk pretty well. It
does, however, make it very inconvenient to deal with dynamically generated inputs
or inputs stored someplace else.

The classic example here, would be, resources. For example, I very much like to keep
my unit tests as independent from the environment and as self-hosting as possible.
One very nice way of doing this is to store necessary input files as embedded resources
on my testing assembly. I do this all the time with PipelineTesting and
it works great. However, since you can’t provide streams instead of file paths to
the BizTalk 2009 testing features, you’d need to first save the embedded resource
to a temporary file, which adds a bit of friction to the process.

Compilation Changes

My biggest gripe with the Unit Testing features, is that enabling them implies a change
in the build process, that changes the generated code for the BizTalk artifacts themselves.

When you enable the Unit Testing option in Project -> Properties -> Deployment,
the compilation process will change the generated CLR types so that they inherit from
the TestableXXX classes defined in the Microsoft.BizTalk.TestTools.dll assembly,
instead of the normal BizTalk artifact classes.

These new Testable base classes, in turn, derive from the original BizTalk classes,
so the change isn’t all that big. However, it does smell wrong. Could it
introduce any problems/bugs if you were to enable the testing features for all builds?
Hopefully no, but no way to know until you run into them.

Of course, you could just enable Unit Testing for debug builds, but then you can’t
run your unit tests on the release builds of your BizTalk assemblies. It also introduces
yet another asymmetry between development and deployment builds which, to be honest,
makes me somewhat nervous.

Conclusion

The new Unit Testing features in BizTalk Server 2009 are a sorely needed and welcome
feature, if somewhat lacking in the first beta.

Will it improve? On one hand, I’m somewhat optimistic that some improvements might
make an appearance in forthcoming builds. However, I’m also not getting my hopes up,
as MS is notable for trying to avoid significant API changes during after beta 1 hits
the street (BizTalk, unfortunately, doesn’t use the CTP model, where significant API
change requests are more likely to be considered).

[1] TestableMap.TestMap() does throw exceptions on failure instead of
a Boolean return value, but said exceptions might not contain detailed error information.