MSBuild, MSTest, Biztalk and CruiseControl.Net

I've been working on a project that will incorporate a number of pieces of technology: Biztalk, Host Integration Server, Hummingbird Document Management, Sybase, and perhaps a few others.

We're going to use VS2005, the only question is, whether we will be using Team Suite or Professional. If we don't use Team Suite, then we don't have the Microsoft testing tools, so we'll use NUnit instead. But in hopes that when the decision (finally) comes down, that we'll be using Team Suite, I am working on integrating MSBuild and MSTest into CruiseControl.Net, the continuous integration server. (It is definitely not in the cards that we will use Team Foundation Server at this client.)

CruiseControl can run MSBuild tasks directly, so that was easy enough. I worked on building project files for NDoc and MSTest that would be executed by MSBuild. Not so hard to do. I also worked on a CruiseControl task to run the VB6 compiler to compile a VB6 COM application that will simplify the Hummingbird DM API so we don't have to cross the COM/CLR boundary as many times as if we just linked to the DM API directly.

I've also worked on integrating the build output - CruiseControl has a summary for MSTest and MSBuild output, but I modified the MSTest xsl file a bit to show a few more details of the tests - classname, assembly file, duration, as well as the warnings and messages from the testing process. I also created an MsTestDetails.xsl as well that shows all the tests, the passes and the failures, accessible from the CruiseControl portal sidebar.

Today I began to work on the MSTest coverage results. WHAMMO. Big brick wall. Obviously, Microsoft had some kind of scope constraint on this feature, because the test results xml file does not include any of the coverage data. The results.coverage file generated when test coverage is included in MsTest, is a binary file that can be read by one of the assemblies with Team Suite. The CoverageInfo object reads the results file and the instrumented assemblies and symbol files to create a typed dataset. There's stuff about the paths for those files, which I'm not quite clear on today, but essentially I found the process works best if you don't move the files once they've been produced in a build/test session.

So I wrote a command line utility that "converts" the .coverage file into an xml file. It isn't tested yet, but I should get that done tomorrow, and I also hope to make a MsTestCoverage.xsl file to show the coverage results in the CruiseControl portal.

Oh, and the Biztalk thing - we're going to try BizUnit (available on GotDotNet, written by Microsoft Consulting Services) to drive our Biztalk unit tests. I'll keep you posted on this. It looks good.