I'm still pretty amazed how often I see BizTalk developers and teams not use automated testing when building (or more importantly maintaining) their solutions. It's tragic. You take a wonderful platform like BizTalk and then let mission critical systems depend on someone's manual testing for development or enhancements. It is a sure fire recipe for trouble. Amazingly I see the more complex and critical systems relying less and less on automated testing. I think part of that is due to the difficulty in automating some testing activities. AS2 is a great example.

Today I want to present a dozen lines of code that take a handy little app from the SDK and turn it into the driver for your AS2 Unit Testing automation. The Sender sample (Microsoft BizTalk Server 2009\SDK\AS2 Tutorial\Sender) is a simple command line application that sends an AS2 request via an HTTP POST to the local host. The heavy lifting is in creating the HTTP Headers necessary for a valid AS2 request.

The first two statements in the main method in the only class file sender.cs in this project are listed here:

HttpSender TestSender = new HttpSender(http://localhost/Contoso/BTSHttpReceive.dll);

Stream sr = new FileStream(getBizTalkInstallPath() + @"SDK\AS2 Tutorial\X12_00401_864-Sync.edi", FileMode.Open, FileAccess.Read);

As you can see there is nothing terribly special here (other than the clever getBizTalkInstallPath method). Everything is pretty much hard coded, but it doesn't need to be. These few lines take this from an SDK curiosity into a vital testing tool. Simply replace the two lines above with these:

string url = "";

string payload = "";

foreach (string arg in args)

{

if(arg.StartsWith("-url="))

{

url = arg.Replace("-url=", "");

}

if (arg.StartsWith("-file="))

{

payload = arg.Replace("-file=", "");

}

}

if (url == "" || payload == "")

{

Console.WriteLine("Usage: sender -url=http://localhost/BTSHTTPReceive.dll -file=input.txt");

}

HttpSender TestSender = new HttpSender(url);

Stream sr = new FileStream(payload, FileMode.Open, FileAccess.Read);

Now we can test sending an AS2 request with one simple command: sender -url=http://localhost:10101/BTSHTTPReceive.dll -file=RawAS2File.txt

Better still this is dynamic on both the endpoint and the file, so you can test many samples.

Now we're ready to make this even more useful. We turn to our trusty friend BizUnit (which I am so into I'm actually considering a tattoo). BizUnit includes most of the test steps you will ever need, but not one like this. Instead of making a custom BizUnit test step (which honestly couldn't be much easier) we can fall back on the low tech approach and use the existing ExecuteCommandStep. This step is pretty self-explanatory, like most of BizUnit.

<TestStep assemblyPath="" typeName="BizUnit.ExecuteCommandStep">

    <ProcessName>..\..\sender.exe</ProcessName>

    <ProcessParams>-url=http://localhost:10101/BTSHTTPReceive.dll -file=TestData\External\RawAS2File.txt</ProcessParams>

    <WorkingDirectory>..\..</WorkingDirectory>

</TestStep>

This is admittedly low tech. A BizUnit step would avoid the overhead of creating a new process and certainly scale better. The point I am driving to here is that not everything always needs to be so fancy when it comes to automated testing. Sure there are more elegant ways to do these things, but this is Unit Testing not production code. Perhaps most importantly in less time than it took you to read this I had it working and even made several unit tests for it.

And there it is, a few lines of code added to an existing (and importantly widely distributed) piece of code and suddenly we have automated testing for our AS2 solutions.