Using xUnit.Net console runner with VS2008

A blog post by Bembeng Arifin describes how to use xUnit.Net’s console test runner but I wanted to clarify one important point and simplify his recommendations.

I am using xUnit.net with C++/CLI invoking native DLLs and so I need to have the working directory set to where these reside. The settings I use are (note the fixed directory for Command, obviously changing to that of your local install).

Command: C:\thirdparty\xUnit_net\1_6_0\xunit.console.exe
Arguments: $(TargetPath)
Initial Directory: $(BinDir)
Use Output Window: checked

Shown in context in the dialog:

Tool definition window in Visual Studio 2008 showing above settings to use xUnit.net test runner

In case anyone’s curious about the appearance of the above dialog, it was captured on a Mac using Remote Desktop into my Windows 7 box so the rendering lacks a bit of Aero gloss.

We have a standard environment variable pointing to the location of thirdparty code which I wanted to use but the tool definition dialog refused to accept a path for the Command like $(thirdparty)\xUnit_net\blah.exe.

It also refuses to accept just an executable name, even when it’s on the PATH and can be run in a command window with just that executable name.

Bembeng’s post showed using the longer way to compose the Arguments of $(BinDir)$(TargetName)$(TargetExt) but I prefer simply $(TargetPath) which is easier to type and read.

If anyone’s curious, I eventually picked xUnit.net over NUnit and mbUnit/Gallio because it allows for similar parameterised testing but has a GUI test runner that copes with C++/CLI and I like their style and rationale.

Coding Deja Vu – C++/CLI Pointers

Working in C++/CLI for some interoperability code on old C++ I’m porting, I suddenly realised why I’m not having any trouble mentally translating foo^ as Pointer to Foo. Duhh – I spent years working in Object Pascal where the ^ character was the pointer suffix!