Edit: The XSLT file works now (so far as I can tell) and has been updated on my site. The newest version uses the XSLT standard library to do some string manipulation to output a truncated name of the test that actually failed. That library, with instructions on how to install it, is available here. Note, my XSLT file assumes that at least the string.xsl file is in the same directory, however, you can edit it to point to the online version or a standard location if you want.

A little over a year ago, I attended a talk at GDC about unit testing given by the Games From Within guys. Now, I’d had training in unit testing before, but I hadn’t really been that interested in it until this particular talk at GDC. After attending that talk, I started doing unit testing on all of my personal projects, and (as anyone at my previous job could tell you at this point) I became totally convinced that unit testing was an absolute necessity in modern application programming, even in games. Since I was doing my development mostly in C++, I started using UnitTest++ for most everything I was developing. There were a lot of things I liked about UnitTest++:

1. It’s extremely lightweight. I can put both a debug and release library for it into source control for every project that uses it without feeling too bad about it.
2. It’s designed to be run after every build and integrate into Visual Studio’s error window, which is extremely helpful.
3. It’s very easy to debug. You just set your test project as the startup project and you’re good to go.

Now that I’ve gone back to doing development in other languages, I’m trying to force the UnitTest++ workflow onto other unit testing tools. So far, this means working with NUnit, the defacto standard for .NET unit testing. Thankfully, I’ve actually gotten NUnit’s workflow to match the one in UnitTest++, with the exception of being able to put NUnit into source control. For those of you that might be fighting similar fights, here’s what I did:

1. Create an XSLT for NUnit that will output nit test errors in Visual Studio Error Window readable form. I have such an XSLT file here. Note that this XSLT file may not be perfect, but hey, it’s about an hour’s worth of work.
2. Set up nunit-console to run after every build. In the properties for your test project, go into Build Events and in the post-build event command line window, add the command:
   

   C:\Program Files\NUnit 2.4\bin\nunit-console.exe” /transform=NUnit-VSOut.xslt /nologo $(TargetPath)

   Note that your path to nunit may be different than mine. Also you may want to set the “Run the post-build event” option to “When the build updates the project output” so it doesn’t attempt to run even when nothing’s changed.

3. Setup NUnit for debugging. Again in the properties for your test project, go into the Debug pane. Select your start action to be “Start external program” and point it to nunit-console (you can use the NUnit gui here, I just don’t happen to like it). Under “Command line arguments” add the line:
   

   /nologo YourAssembly.dll

   Note, Visual Studio Macros don’t work in the command line arguments section for some unknown reason, so as much as you would like to, you can’t use $(TargetPath) like you normally would.

Now you can set your test project to be the startup project and test as normal, and have your tests run after every build, just like if you were using UnitTest++.