Skip to main content

Getting your MSTEST unit test stdout to show in Jenkins

There is no easy way to say it, the default Jenkins plugin for publishing MSTEST results does not show a unit test's standard output when it fails.

Should you decide you want your standard output shown after all, you'll need to edit the XSLT used to transform the MSTEST result format (trx) into JUnit's format (which is then parsed by Jenkins and finally displayed in its web interface).

To edit this XSLT, search for "mstest-to-junit.xsl" in your Jenkins home directory.

. . . \Jenkins\plugins\mstest\WEB-INF\classes\hudson\plugins\mstest\mstest-to-junit.xsl

Back it up just in case, and copy-paste the following xslt code into it. Restart Jenkins and enjoy your standard output upon test failure.



Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.