Well, I decided to have a crack at it today and see how hard it really was and I managed to get something going.
So here’s where we start. A completed build with no test results showing. Pretty normal situation.
Now I wanted to get something in there so I ran some unit tests (from a completely different solution as it turns out) using NUnit and saved the results to an XML file. Then I wrote an XSLT to transform the nunit xml output into a test result file Visual Studio 2008 would load.
That took some work, and the XSLT is pretty ugly, but eventually I got it to the point where VS loaded the trx file and viewed the results. I then used MSTest to publish the results to the build log (using the /publish options) but even that was a bit problematic as it exposed some issues with GUIDs in the XSLT that I had to deal with, but in the end I got it working, albeit manually at this stage.
It does mean that the build server will need MSTest installed on it, but at least all the development team can have a bit more flexibility in their testing tools, and don't have to migrate all their Nunit tests to MSTest just to get them in the build log.
The process is pretty simple
- Run Nunit-console and produce an XML log file
- Convert the Nunit XML output to an MSTest test results file (with a .trx extension)
- Use MSTest /publish to push merge the trx file with an existing build
So here’s the result, and surprisingly enough it looks just like a normal TFS team build log:
And if I click the build results? Yep – they load up as expected as well.
And clicking through to an individual test gives me something like this:
And because it's a published build, the test results appear in the data warehouse as well, available for reporting as seen here:
At this point this is all just proving a point, and it’s still very much a manual process. Also I’ve only tried loading test results where all tests are passing but it's working and I think it's a good start for doing things properly. Assuming there's enough interest I'll try and turn this into something that can be used in a build process - maybe write it as an MSBuild custom task or something like that.
Let me know if you'd like to see me put some more effort into this or if you've got any feedback.